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IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Digital Enhanced Cordless 
Telecommunications (DECT). 

The present document is based on EN 300 175 parts 1 [1] to 8 [8] and EN 300 444 [12]. General attachment 
requirements and speech attachment requirements are based on EN 301 406 [11] (replacing TBR 006 [i.2]) and 
EN 300 176-2 [10] (previously covered by TBR 010 [i.3]). Further details of the DECT system may be found in 
TR 101 178 [i.l]. 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [13]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales. 

The present document is part 3 of a multi-part deliverable covering the New Generation DECT as identified below: 
Part 1: "Wideband speech"; 
Part 2: "Support of transparent IP packet data"; 
Part 3: "Extended wideband speech services"; 

Part 4: "Light Data Services: Software Update Over The Air (SUOTA), Content Downloading and HTTP based 
applications ". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 
The New Generation DECT provides the following basic new functionalities: 

• Wideband speech service (part 1 of this multi-part deliverable [21]). 

• Packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates (part 2 
of this mutli-part deliverable [i.4]). 

• Extended wideband speech services (the present document). 

• Light Data Services: Software Update Over The Air (SUOTA), Content Downloading and HTTP based 
applications (part 4 of this mutli-part deliverable [i.5]). 

All New Generation DECT devices will offer at least one or several of these services. 

The present document describes the part 3: Extended wideband speech services: 

• For the description of the wideband speech service, see TS 102 527-1 [21]. 

• For the description of the support of transparent IP packet data, see TS 102 527-2 [i.4]. 

• For the description of the Light Data Services: Software Update Over The Air (SUOTA), Content 
Downloading and HTTP based applications, see TS 102 527-4 [i.5]. 

The part 3 "Extended wideband speech services" is defined as an extension of part 1 of this mutU-part deliverable 
"Wideband speech service" [21]. All devices compliant to part 3 specification (the present document) shall implement 
at least all mandatory features and may implement the optional features defined in part 1 "Wideband speech" [21]. In 
addition to that, the present document defines additional mandatory or optional features. 

The part 1 [21], and therefore part 3, are also defined as extensions of the "Generic Access Profile (GAP)" [12]. All 
DECT devices offering Wideband speech services (part 1 or part 1 plus part 3) shall also be compliant with the 
"Generic Access Profile (GAP)" [12], and shall offer the DECT standard 32 kbit/s voice service according to GAP. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT wideband speech applications, with the features of the present document being a common 
fall-back option available in all compliant to this profile equipment. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 
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NOTE: While any hyperlinks included in this clause were vaUd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) appUes. 

[I] ETSI EN 300 175-1 : "Digital Enhanced Cordless Teleconnmunications (DECT); Conmion 
Interface (CI); Part 1: Overview". 

[2] ETSI EN 300 175-2: "Digital Enhanced Cordless Teleconnmunications (DECT); Common 

Interface (CI); Part 2: Physical layer (PHL)". 

[3] ETSI EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 3: Medium Access Control (MAC) layer". 

[4] ETSI EN 300 175-4: "Digital Enhanced Cordless Teleconnmunications (DECT); Common 

Interface (CI); Part 4: Data Link Control (DEC) layer". 

[5] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 5: Network (NWK) layer". 

[6] ETSI EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Connmon 

Interface (CI); Part 6: Identities and addressing". 

[7] ETSI EN 300 175-7: "Digital Enhanced Cordless Teleconnmunications (DECT); Connmon 

Interface (CI); Part 7: Security features". 

[8] ETSI EN 300 175-8: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 8: Speech and audio coding and transmission". 

[9] Void. 

[10] ETSI EN 300 176-2: "Digital Enhanced Cordless Telecommunications (DECT); Test 

specification; Part 2: Audio and speech". 

[II] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 
Digital Enhanced Cordless Telecommunications (DECT) covering the essential requirements 
under article 3.2 of the R&TTE Directive; Generic radio". 

[12] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 

Profile (GAP)". 

[13] ISO/IEC 9646-6: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 6: Protocol profile test specification". 

[14] ISO/IEC 9646-7: "Information technology - Open Systems Intercoimection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[15] ITU-T Recommendation G.726 (1990): "40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code 

Modulation (ADPCM) ". 

[16] ITU-T Reconunendation G.711 (1988): "Pulse code modulation (PCM) of voice frequencies". 

[17] ITU-T Reconnmendation G.722 (1988): "7 kHz audio-coding within 64 kbit/s" . 

[18] ITU-T Recommendation G.729. 1 (2006): "G.729 based Embedded Variable bit-rate coder: An 

8-32 kbit/s scalable wideband coder bitstream interoperable with G.729". 

[19] ISO/IEC JTC1/SC29AVG1 1 (MPEG): International Standard ISO/IEC 14496-3:2005/ 

AMD 1:2007: "Coding of audio- visual objects - Part 3: Audio; AMENDMENT 1: Low Delay 
AAC profile". 
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[20] ISO/IEC JTC1/SC29AVG1 1 (MPEG): International Standard ISO/IEC 14496-3:2005: 

"Information Technology - Coding of audio-visual objects - Part 3: Audio". 

[21] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband Speech". . 

[22] ETSI TS 122 072: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Call Deflection (CD); Stage 1 (3GPP TS 22.072 
version 9.0.0 Release 9)". 

[23] ETSI TS 122 081: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Line Identification supplementary services; Stage 1 
(3GPPTS 22.081)". 

[24] ETSI TS 122 082: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Call Forwarding (CP) Supplementary Services; 
Stage 1 (3GPP TS 22.082)". 

[25] ETSI TS 123 082: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Call Forwarding (CF) supplementary services; Stage 2 
(3GPPTS 23.082)". 

[26] ETSI TS 124 082: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Call Forwarding (CF) supplementary services; Stage 3 
(3GPPTS 24.082)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 101 178: "Digital Enhanced Cordless Telecommunications (DECT); A high Level Guide 

to the DECT Standardization". 

[i.2] ETSI TBR 006: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements". 

[i.3J ETSI TBR 010: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements: Telephony applications". 

[i.4] ETSI TS 102 527-2: "Digital Enhanced Cordless Teleconmiunications (DECT); New Generation 

DECT; Part 2: Support of transparent IP packet data". 

[i.5] ETSI TS 102 527-4: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 4: Light Data Services; Software Update Over The Air (SUOTA), content 
downloading and HTTP based applications". 

[i.6] ITU-T Recommendation P.31 1 (2005): "Transmission characteristics for wideband (150-7000 Hz) 

digital handset telephones". 

[i.7] ITU-T Recommendation G.729: "Coding of speech at 8 kbit/s using conjugate structure 

algebraic-code-excited linear prediction (CS-ACELP)". 

[i.8] ITU-T Recommendation Q.23 (1988): "Technical features of push-button telephone sets",. 

[i.9] ITU-T Recommendation Q.24 (1988): " Multifrequency push-button signal reception". 

[i.lO] ITU-T Recommendation E.180: "Technical characteristics of tones for the telephone service". 

[i.l 1] ITU-T Recommendation E.180- Supplement 2: "Various tones used in national networks". 

[i.l2] ITU-T Recommendation E.182: "AppUcation of tones and recorded announcements in telephone 

services". 
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3 



Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in EN 300 444 [12] and the following apply: 

call status: part of the call information sent from FP to PP about the FP call state toward the peer party 

double call with in-band signalling (line): legacy line on which second calls-incoming or outgoing- are handled using 
signalling "in-band" 

FP-managed line selection: mode for an outgoing external call, in which the PP does not indicate the Une to be used to 

the FP and the FP chooses the line where the call is placed 

GAP (PP or FP) : PP or FP comphant with EN 300 444 [12]. 

Headset PP (HPP): wireless headset telephone using the DECT air interface 

NOTE: A HPP usually has only one speaker and one microphone combined with a limited set of keys (e.g. call 
button, volume plus, and volume minus). Headsets provide the equivalent functionality of a PP with 
hands-free operation. 

late release: sending of a "CS idle" call status by the FP for a call that has been released a long time before in the 



NOTE: See clause 7.4.3.10.3.1. 

line: logical channel, separately accessible from the external world through a dedicated external directory entry 
(e.g. telephone number, uri, etc.) 

NOTE: These lines may be of various types, for example: PSTN, VoIP or ISDN Unes. 

multiple call line: hne supporting several simultaneous (external) calls 

NOTE: An example of multiple call line is a VoIP Une used with the SIP protocol. 

multiple-call mode: configuration mode of a multiple call line from a DECT system point of view, enabUng several 
simultaneous incoming or outgoing calls on different PPs (i.e. this possibility is not disabled by configuration) 

new generation DECT: further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements 

none: special line identifier value defined in clause 7.7.56 of EN 300 175 5 [5], used to indicate that the line id for the 
external call is not yet known. 

NOTE: It is used for FP managed hne selection (clauses 7.4.3.5. 1 and 7.4.5.2.4) and, as a special case, for call 
intrusion (clause 7.4.3.8). 

NG-DECT Part 1 (PP or FP) : PP or FP comphant with TS 102 527-1 [21]. 

NG-DECT Part 3 (PP or FP) : PP or FP comphant with the present document. 

off-hook CLIP: abiUty of a network to send CLIP information for a waiting call (also known as "CLIP on call waiting" 

or "CLIP phase 11") 

single-call mode: configuration mode of a multiple call line from a DECT system point of view, in which the 
possibihty of making several fully parallel call is (temporarily) disabled 

NOTE: This mode may be useful for a user alone in the home. This mode does not prevent several simultaneous 
calls on the same PP. A line which is not "multiple call" (for instance a PSTN line only enabling double 
calls) is also said to be in "single call" mode. 

super- wideband speech: voice service with enhanced quahty compared to ADPCM G.726 and allowing the 
transmission of a maximum vocal frequency of at least 14 kHz 



network 
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wideband speech: voice service with enhanced quahty compared to ADPCM G.726 and allowing the transmission of a 
vocal frequency range of at least 150 Hz to 7 kHz, and fulfilling, at least, the audio performance requirements described 
in the ITU-T Recommendation P.3 1 1 [i.6] 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

M mandatory to support (provision mandatory, process mandatory) 

optional to support (provision optional, process mandatory) 

1 out-of-scope (provision optional, process optional) not subject for testing 
C conditional to support (process mandatory) 

N/A not appUcable (in the given context the specification makes it impossible to use this capabiUty) 

Provision mandatory, process mandatory means that the indicated feature service or procedure shall be implemented as 
described in the present document, and may be subject to testing. 

Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, and 
if implemented, the feature, service or procedure shall be implemented as described in the present document, and may 
be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 [14]. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AAC 


Advanced Audio Coding (MPEG) 


AC 


Authentication Code 


ADPCM 


Adaptive Differential Pulse Code Modulation 


Al 


Air Interface 


CC 


Call Control 


CFB 


Call Forwarding on Busy 


CFNA 


Call Forwarding on No Answer 


CFU 


Call Forwarding Unconditional 


CI 


Common Interface 


CLIP 


Calling Line Identification Presentation 


CLIR 


Calling Line Identity Restriction 


CNIP 


Calhng Name Identification Presentation 


DCIBS 


Double Call with In-Band Signalling 


DECT 


Digital Enhanced Cordless Telecommunications 


DLC 


Data Link Control 


DNS 


Domain Name System 


DTMF 


Dual Tone Multi-Frequency 


ER 


Error Resilient (MPEG) 


FP 


Fixed Part 


FT 


Fixed radio Termination 


GAP 


Generic Access Profile 


GMT 


Greenwich Mean Time 


HPP 


Headset Portable Part 


HTTP 


HyperText Transfer Protocol 


lA 


Implementation Alternative 


IE 


Information Element 


IP 


Internet Protocol 


IPUl 


International Portable User Identity 


ISDN 


Integrated Services Digital Network 


IWU 


InterWorking Unit 


LA 


Location Area 


LD 


Low Delay (MPEG) 


LiA 


List Access 


LLME 


Lower Layer Management Entity 
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MAC 


Medium Access Control 


MM 


Mobility Management 


MMI 


Man Machine Interface 


NG 


New Generation 


NG-DECT 


New Generation DECT 


NWK 


NetWorK 


P 


Public (environment) 


PARK 


Portable Access Rights Key 


PHL 


PHysical Layer 


PP 


Portable Part 


PSTN 


Public Switched Telephone Network 


PT 


Portable radio Termination 


R/B 


Residential/Business (environment) 


RFP 


Radio Fixed Part 


S/T 


ISDN S/T Interface 


SARI 


Secondary Access Rights Identity 


TCLw 


weighted Telephone Coupling Loss 


TPUI 


Temporary Portable User Identity 


TRUP 


TRansparent UnProtected service 


U 


ISDN U-Interface 


UMT 


Universal Mean Time 


VoIP 


Voice over IP 


WB 


WideBand 


SUOTA 


Software Update Over The Air 


ISBC 


??? 


MWI 


Message Waiting Indication 



4 Description of Services 
4.1 Enhanced wideband speech 

The present document is defined as an extension of New Generation DECT; part 1: wideband speech 
(TS 102 527-1 [21]). All devices compliant with the present document shall implement wideband (150 Hz to 7 kHz) 
audio with 1 6 kHz frequency sampling, and shall implement, at least, the speech coding format according to 
ITU-T Recommendation G.722 [17]. In addition to that, other wideband and superwideband audio codecs, providing 
even better audio quality, may be implemented. 

See TS 102 527-1 [21], clause 4.1 for description about wideband speech. 

4.1 .1 Back-compatibility witli GAP 

The present document is backcompatible with Generic Access Profile (GAP) EN 300 444 [12|. All devices compliant 
with the present dociunent shall implement ADPCM narrowband speech service according to ITU-T Recommendation 
G.726 [15], with automatic detection of the capabilities of the other peer. 

4.1 .2 Furtlier enliancement in audio performance requirements 

The present document implements a further enhancement in acoustic wideband performance compared to 
TS 102 527-1 [21]: the more demanding audio specifications PP types 2b and 2c (see EN 300 175-8 [8]) are mandatory 
for all PPs comphant with the present document. With this extra requirement, the acustic performance of the wideband 
speech service will be even better than the ITU standard for wideband audio, ITU-T Recommendation P.311 [i.6]. 

See also TS 102 527-1 [21], clause 4.1.1. 
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The present document implements also a further enhancement in acoustic performance for 3,1 kHz narrowband service 
compared to GAP (EN 300 444 [12]) and TS 102 527-1 [21]: the more demanding audio specifications for PP types Ic 
and Id (see EN 300 175-8 [8]) are mandatory for all PPs compliant with the present document. With this extra 
requirement, the acoustic performance of PPs compliant with the present document, when operating in 3, 1 kHz 
narrowband service, will be even better than classic DECT/GAP specification. 

All audio types used by the present document are compatible with VoIP or long delay networks. 

4.2 Wideband speech scenarios 

See TS 102 527-1 [21], clause 4.2. 

4.3 Extended wideband speech services defined in the present 
document 

The following additional services are provided by the present document, compared to TS 102 527-1 [21]: 

• More demanding audio specifications for both; wideband and narrowband (see clause 4. 1 .2). 

• New simplified, "easy pairing" procedures. 

• New "no-emision" mode in FPs (switching down the dummy bearer when in idle mode). 

• Date and time synchronization. 

• CLIP and CNIP are now mandatory features. 

• Internal call and wideband Internal call (mandatory features). 

• CLIP and CNIP for Internal calls (mandatory features). 

• Generic Event notification mechanism, providing support for: 

Message waiting indication. 
Missed call notification. 

• List access service. 

• HandUng of multiple calls between the same PP and the REP. 

• CLIP and CNIP on call waiting. 

• CLIP and CNIP on call transfer. 

• Call deflection. 

• Call identification and Line identification features. 

• CLIR feature. 

• Multiple calls and multiple lines features. 

• Mutualised parallel calls. 

• New system settings and line settings. 

• Informative annexes with more examples of flowcharts, including system settings, multiple calls and parallel 
calls. 

The new extended services, take in to account the additional scenarios possible in DECT systems connected to the 
network via VoIP interfaces. 
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5 



Service and feature definitions 



5.1 



New Generation DECT Speech Services 



For the purposes of the present document, the definitions of TS 102 527-1 [21], clause 5.1 shall apply. 



5.2 



Network (NWK) features 



For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.2 and EN 300 444 [12], 
clause 4.1, plus the following shall apply: 

Missed call notification [NG1.N.3]: ability to inform a user that a call has been missed. 

Voice message waiting notification [NG1.N.4]: ability to inform a user that a voice message has been left in the voice 

mailbox to which the user has access. 

Date and time synchronization [NG1.N.5]: ability to synchronize the date and time on the DECT system. From FP to 
all registered PP or from one registered PP to the FP. 

Parallel calls [NG1.N.6]: ability to handle in the DECT system two or more simultaneous calls originated or 
terminated in the same PP. 

Common parallel call procedures (external or internal) [NG1.N.7]: set of common procedures for handling PSTN 
double calls, SIP multiple calls on a single Une, as well as parallel call situations occurring in a multiple line DECT 

system. 

Call transfer (internal or external) [NG1.N.8]: abihty to create a new call while already involved in a call and 
connect the remote party to it (kind of parallel calls). 

3-party conference call (internal or external) [NG1.N.9]: ability to connect the local party and the two remote parties 
of two parallels calls into a single conference (kind of parallel calls). 

Intrusion call [NG1.N.10]: ability for a PP not participating to an already estabUshed call to cormect to it (kind of 
parallel calls). Intrusion call is also known as "barging in". 

Call deflection [NG1.N.11]: abiUty to redirect an incoming call during the call presentation to another user. 

Line identification [NG1.N.12]: abiUty to exchange between the PP and FP a line identifier for external calls. 

Call identification [NG1.N.13]: abiUty to exchange between the PP and FP a call identifier assigned by the FP at call 
setup and call statuses from FP to PP. 

Multiple lines [NG1.N.14]: abiUty for a DECT System to handle several external lines. 

Multiple calls [NG1.N.15]: ability for a DECT System to handle a line supporting several simultaneous external calls. 

List access service [NG1.N.16]: abiUty to store information on the DECT system in a set of lists on the FP and manage 
these Usts from the PP. 

Calling Line Identity Restriction (CLIR) [NG1.N.17]: abihty for the user to hide the identity of his line (i.e. CaUing 
Line Identity Presentation) to the caUed party. 

Call forwarding [NG1.N.18]: abiUty to request to the network a redirection of incoming caUs. 

DTMF handling [NG1.N.19]: ability to handle DTMF signalUng and generation. 

Tones provision [NG1.N.20]: ability to support complete call progress tones generation. 

Headset management [NG1.N.21]: abiUty to handle calls with a headset PP in a DECT system. 

HandUng of Unes where second calls are signalled in-band [NG1.N.22]: ability to handle second caUs on PSTN lines 
or Unes foUowing similar rules. 
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5.3 Data Link Control (DLC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21J, clause 5.3 and EN 300 444 [12], 
clause 5.1 shall apply. 

5.4 IVIedium Access Control (MAC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.4 and EN 300 444 [12], 
clause 5.2, plus the following shall apply: 

"no emission" mode [NG1.M.5]: ability to deactivate all radio transmissions in a DECT FP when it does not handle 
any call. Power-down is negotiated and an algorithm is provided, that guarantees a short resynchronization time, if an 
RF-cormection is required by any of the peers. 

5.5 Physical Layer (PHL) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.5 shall apply. 

5.6 Speech coding and audio feature definitions 

For the piuposes of the present document, all definitions of TS 102 527-1 [21], clause 5.6 shall apply. 

5.7 Application features 

For the purposes of the present document, all definitions of EN 300 444 [12], clause 4.2 plus the following shall apply. 

Easy PIN code registration [NG1.A.1]: ability to invite the user to register a PP that is not registered to a FP. The 

access rights procedure is triggered by PIN entering. 

Easy pairing registration [NG1.A.2]: abiUty to register a PP that is not registered to a FP by pressing a physical or 
logical button on the PP and on the FP. 

Handset locator [NG1.A.3]: ability to locate physically handsets (have them ring) by pressing a physical or logical 
button on the FP. 



6 Inter-operability requirements 
6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures) which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. In the case of FT, the status can be different for products intended for the 
Residential/Business (R/B) market or for the Public market segment. 

All optional elements shall be process mandatory according to the procedures described in the present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present docimient. 

New Generation DECT wideband speech is defined as a backcompatible enhancement of EN 300 444 [12] (Generic 
Access Profile (GAP)). All procedures not specific of the New Generation DECT, are referenced to their original 
description in EN 300 444 [12] (GAP). 

The requirements of EN 301 406 [11] and EN 300 176-2 [10] shall be met by all equipment conforming to the present 
document. 



ETSI 



21 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



6.2 New Generation DECT Speech Services support status 

The following end-user services shall be supported by "New Generation DECT; part 3: Extended wideband speech 
services" devices shall support the following end-user services. 



Table 1 : Speech service status 



Feature supported 




Status 


Item no. 


Name of Service 


Reference 


PT 


FT 


R/B 


P 


NG1.1 


Narrow band ADPCM G.726 32 kbit/s voice service 


5.1 [21] 


IVI 


M 


M 


NG1.2 


Narrow band PCM G.71 1 64 WbWs voice service 


5.1 [211 











NG1.3 


Wideband G.722 64 kbit/s voice service 


5.1 [21] 


IVI 


M 


M 


NG1.4 


Wideband G.729.1 32 kbit/s voice service 


5.1 [21] 











NG1.5 


l\/IPEG-4 ER AAC-LD super wideband 64 kbit/s voice service 


5.1 [21] 











NG1.6 


l\/IPEG-4 ER AAC-LD wideband 32 kbit/s voice service 


5.1 [21] 












6.3 Services to DECT feature implementation mappings 

"New Generation DECT; part 3: Extended wideband speech services" end user services shall be implemented using the 
DECT features and implementation alternatives defined in table 2. 



Table 2: Speech service to DECT features implementation mappings 



Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1.1 Narrow band ADPCiUI 
G.726 32 kb'Ws voice service 


i 




5.1 [21] 


iUI 


iUI 


iUI 






NG1 .P.I 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1 .P.2 Physical Packet P32 


5.5 [21] 


M 


M 


M 






NG1.M.1 lN_minimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






GAP.M.4 Basic Connections 


5.2 [12] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


C201 


C201 


C201 






NG1 .D.I DLC Service LU1 TRUP Class 

0/min delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.1 ITU-T Recommendation 
G.726 [15] 32 kbit/s ADPCM codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.10 PP Audio type la (classic 
GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1.SC.11 PP Audio type lb 
(improved GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1 .SCI 2 PP Audio type 1 c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SCI 3 PP Audio type 1 d (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SCI 7 PP Audio type 3a (HATS 

3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.23 FP Audio type lb (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 






NG1 .SC.27 FP Audio type 3 (VoIP 

3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC. 32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC. 33 FP Audio type 6d (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 

CD 

rr 


5.6 [21] 


N/A 


o 


o 


Noi.^ Narrow Dana rUM u.rii 


1 
1 




c ^ roi 1 

0.1 [illj 


U 








64 l<bit/s voice service 




NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1 .P. 3 Priysical Packet P64 


5.5 [21] 


M 


M 


M 






NG1.M.1 lN_mlnimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.I DLC Service LUI TRUP Class 
O/mindelay 


5.3 [21] 


M 


M 


M 






NG1 .D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.2 ITU-T Recommendation 
G.71 1 [16] 64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.8 Detection of Fax/modem 
tone 


5.6 [21] 















NG1 .SC.9 Codec selection and 

switching 


5.6 [21] 


M 


M 


M 






NG1.SC.10 PP Audio type la (classic 
GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1.SC.11 PP Audio type lb 
(Improved GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1.SC.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.17 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.23 FP Audio type lb (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC. 24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.32 FP Audio type 6a (internal 

call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (Internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


r(/D 


□ 
r 


iMui.^ Narrow Dana kum u.rii 


II 




CI ^o^^ 


U 








64 l(bit/s voice service 




NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.4 Physical Packet P67 


5.5 [21] 


M 


M 


M 






NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .MA Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.1 DLC Service LU1 TRUP Class 
0/min_delay 


5.3 [21] 


M 


M 


M 






NG1 .D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.2 ITU-T Recommendation 
G.71 1 [16] 64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.8 Detection of Fax/modem 

tone 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1 .SC.1 PP Audio type 1 a (classic 

GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1 .SC.1 2 PP Audio type 1 c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SC. 1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.1 8 PP Audio type 3b (HATS 

3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC. 23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .80.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


G707 


G707 






NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 

3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


r(/D 


□ 

r 


iMui.^ Narrow oana rum u.rii 


III 
III 




CI ^o^^ 


u 








64 l(bit/s voice service 




NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.5 Physical Packet P80 


5.5 [21] 


M 


M 


M 






NG1 .M.2 lN_normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 MA Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.3 DLC service LU7 64 kb\Us 
protected bearer service 


5.3 [21] 


M 


M 


M 






NG1 .D.6 DLC frame FU7 


5.3 [21] 


M 


M 


M 






NG1 .SC.2 ITU-T Recommendation 
G.71 1 [16] 64 kbit/s PCIVI codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.8 Detection of Fax/modem 

tone 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1 .SC.1 PR Audio type 1 a (classic 

GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1 .SC.1 2 PP Audio type 1 c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SC. 1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.1 8 PP Audio type 3b (HATS 

3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC. 23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .80.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


G707 


G707 






NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 

3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.32 FP Audio type 6a (internal 

call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


Hid 


□ 
r 


iMuLo wiaeDana i Kriz u./^^ 


1 
1 




c i ^o^^ 


n/i 


M 


M 


64 l(bit/s voice service 




NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 






NG1.M.1 lN_minimum delay symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.1 DLG Service LU1 TRUP Class 
0/min_delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.3 ITU-T Recommendation 
G.722 [17] 64 kbit/s 7 kHz wideband 

codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.7 Packet loss Concealment 
(PLC) for ITU-T Recommendation 
G.722 [17] 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1 .SC.1 4 PP Audio type 2a 
(ITU-T Recommendation P.311 [i.6] 
7 kHz handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1 .SC.1 5 PP Audio type 2b (HATS 

7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 

wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 30 NG1 .SC. 24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1.SC.24 PP echo 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC.32 FP Audio type 6a (internal 

call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


r(/D 


□ 

r 


Nui.o wiaeDana i Kriz u./^^ 


II 




c i ^o^^ 


u 








64 l(bit/s voice service 




NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P67 


5.5 [21] 


M 


M 


M 






NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .MA Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.1 DLC Service LU1 TRUP Class 
0/min_delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.3 ITU-T Recommendation 
G.722 [17] 64 kbit/s 7 kHz wideband 

codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.7 Packet loss Concealment 
(PLC) for ITU-T Recommendation 
G.722 [17] 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.14 PP Audio type 2a 
(ITU-T Recommendation P.311 [i.6] 
7 kHz handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1 .SCI 5 PP Audio type 2b (HATS 

7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 

wideband 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 30 NG1 .SC. 24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1.SC.24 PP echo 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC.32 FP Audio type 6a (internal 

call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1.4 Wideband 7 l<Hz G.729.1 


1 




5.1 [21] 





O 


o 


0£. KDII/S vOICc SGrVICG 




Nbl .P.I 2 level GFbK moaulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P32 


5.5 [21] 


M 


M 


M 






NG1 .M.2 lN_normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 MA Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.4 DLC service LU12 (UNF) 

Class 


5.3 [21] 


M 


M 


M 






NG1.D.7 DLC frame FU12 witti 
adaptation for codec G.729.1 


5.3 [21] 


M 


M 


M 






NG1 .SC.4 ITU-T Recommendation 
G.729.1 [18] 32 Vb\Ms 7 kHz wideband 

codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1 .SCI 4 PP Audio type 2a 
(ITU-T Recommendation P.311 [i.6] 
7 kHz handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1.SC.15 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SCI 6 PP Audio type 2c (HATS 

7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SCI 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 

wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC29 FP Audio type 5 (VoIP 
wideband 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.30 NG1 .SC. 24 PP echo 

canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1.SC.24 PP echo 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1.5 Superwideband 14 kHz 


1 




5.1 [21] 





KJ 


KJ 






NUI.r.l ^ IGVei oror\ rnouuiHtion 


0.0 [tl\ J 


M 


M 


M 


voice service 




NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 






NG1 .M.2 lN_normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 MA Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.2 DLC Service LU1 Class 


5.4 [21] 


M 


M 


M 






NG1 .D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 14 
kHz superwideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1 .SC.21 PP Audio type 5a 
(Superwideband 1 4 KHz handset) 


5.6 [21] 


M 


N/A 


N/A 






NG1 .SC.22 PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 

wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 32 FP Audio type 6a (internal 

call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC. 33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 


O 


O 






NG1 .SC. 34 Adaptive volume control for 
PP 

r r 


o.b [^1J 


N/A 


u 


u 


NG1.5 Superwideband 14 kHz 


il 




5.1 [21] 





KJ 


KJ 






iNoi .r. 1 level oroix mouuiation 


0.0 J 


M 


M 


M 


voice service 




NG1 .P.3 Physical Packet P67 


5.5 [21] 


M 


M 


M 






NG1 .M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.2 DLC service LU1 Class 


5.3 [21] 


M 


M 


M 






NG1 .D.5 DLC frame Fill 


5.3 [21] 


M 


M 


M 






NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1 .SC.21 PP Audio type 5a 
(Supenwideband 1 4 KHz handset) 


5.6 [21] 


M 


N/A 


N/A 






NG1 .SC.22 PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.32 FP Audio type 6a (internal 

call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


p 


NG1.6 Wideband 11 l<Hz iUIPEG-4 


1 




5.1 [21] 





KJ 


KJ 






Nui.r.i ^ level oror\ moouiation 


0.0 [tl\ J 


M 


M 


M 


service 




NG1.P.3 Physical Packet P32 


5.5 [21] 


IVI 


IVI 


M 






NG1 .M.2 lN_normal_delay symmetric 
MAG service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Gonnections 


5.4 [21] 


IVI 


IVI 


M 






NG1 .D.2 DLG service LU1 Glass 


5.4 [21] 


M 


M 


M 






NG1.D.5 DLG frame FU1 


5.3 [21] 


IVI 


IVI 


M 






NG1 .SG.6 MPEG4 AAG-LD 32 kbit/s 
1 1 kHz wideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SG.9 Godec selection and 
switching 


5.6 [21] 


IVI 


IVI 


M 






NG1.SG.14 PP Audio type 2a 
(ITU-T Recommendation P.311 [i.6] 
7 kHz handset) 


5.6 [21] 


1 


N/A 


N/A 






NG1 .SG.1 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


G703 


N/A 


N/A 






NG1 .SG.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


G703 


N/A 


N/A 






NG1 .SG.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SG.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SG.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


G708 


G708 






NG1 .SG.29 FP Audio type 5 (VoIP 

wideband) 


5.6 [21] 


N/A 


G708 


G708 






NG1 .SG.30 NG1 .SG.24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


G709 


G709 






NG1. 80.31 NG1 .SC.24 PP echo 
supressor for FP, wideband 


5.6 [21] 


N/A 


O709 


O709 






NG1 .SG.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SG.33 FP Audio type 6b (internal 

conference) 


5.6 [21] 


N/A 












NG1 .80.34 Adaptive volume control 


5.6 [211 


N/A 








lA = Implementation Alternative: 

C201 : Advanced connections for Service NG1 .1 shall only be used in the case of multiple connections 

between the same PT-FT pair. The support of this case is optional. 
C702: At least one should be provided. C703:At least one should be provided.). 
C706: At least one should be provided. 

C707: IF feature NG1 .SC.23 (FP type 1 b) OR NG1 .SG.27 (FP type 3) THEN ELSE 1. Either NG1 .SC.24 or 

NG1 .SG.25 may be provided, but not both at the same time. 
C708: At least one should be provided. 

C709: IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN ELSE 1. Either NG1 .SC.30 or 
NG1 .SC.31 may be provided, but not both at the same time. 
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6.4 NWK features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Network 
layer features. 



Table 3: NWK features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


R/B 


p 


NG1.N.1 


Codec Neqotiation 


5.2 [21] 


IVI 


M 


M 


NG1.N.2 


Codec Switching 


5.2 [21] 

L J 


M 


M 


M 


NG1.N.3 


Missed call notification 


5.2 


M 


M 


M 


NG1.N.4 


Voice message waiting notification 


5.2 


M 


M 


M 


NG1.N.5 


Date and Time synchronization 


5.2 


IV! 


M 


M 


NG1.N.6 


Parallel calls 


5.2 


IVI 


M, 
note 7 





NG1.N.7 


Common parallel call procedures (external or Internal) 


5.2 


IVI 


M, 
note 7 





NG1.N.8 


Call transfer (external or Internal) 


5.2 


IVI 


M 





NG1.N.9 


3-party conference with established external and/or Internal 
calls 


5.2 





0, 
note 6 


0, 
note 6 


NG1.N.10 


Intrusion call 


5.2 





0, 
note 6 


0, 
note 6 


NG1.N.11 


Call deflection (external or Internal) 


5.2 





0, 
note 6 


0, 
note 6 


NG1.N.12 


Line Identification 


5.2 


IV! 


M 


M 


NG1.N.13 


Call Identification 


5.2 


IV! 


M 


M 


NG1.N.14 


IVIultiple Lines 


5.2 


IV! 








NG1.N.15 


IVlultiple calls 


5.2 


IV! 


M 





NG1.N.16 


List access service 


5.2 


IV! 


M 





NG1.N.17 


Galling line identity restriction 


5.2 











NG1.N.18 


Call forwarding (external calls) 


5.2 


IVI 


IVI 


1 


NG1.N.19 


DTIVIF handling 


5.2 


IVI 


M 





NG1.N.20 


Tones provision 


5.2 


IV! 


M 





NG1.N.21 


Headset management 


5.2 


C301 


M 





NG1.N.22 


Handling of lines where second calls are signalled In-band 


5.2 


IV! 


0, 
note 7 





GAP.N.1 


Outgoing call 


4.1 [12] 


IV! 


M 


IVI 


GAP.N.2 


Off hook 


4.1 [12] 


IV! 


M 


M 


GAP.N.3 


On hook (full release) 


4.1 [12] 


IV! 


M 


M 


GAP.N.4 


Dialled digits (basic) 


4.1 [12] 


IVI 


M 


M 


GAP.N.5 


Register recall (see notes 4 and 5) 


4.1 [12] 


IV! 








GAP.N.6 


Go to DTIVIF signalling (defined tone length) (see note 1) 


4.1 [12] 


M 





M 


GAP.N.7 


Pause (dialling pause) (see note 3) 


4.1 [12] 


IVI 








GAP.N.8 


Incoming call 


4.1 [12] 


M 


M 


M 


GAP.N.9 


Authentication of PP 


4.1 [12] 


M 


M 


M 


GAP.N10 


Authentication of user (see note 2) 


4.1 [12] 


M 








GAP.N.11 


Location registration 


4.1 [12] 


M 





M 


GAP.N.1 2 


On air key allocation (see note 2) 


4.1 [12] 


M 


M 





GAP.N.1 3 


Identification of PP 


4.1 [12] 


IV! 








GAP.N.14 


Service class Indication/assignment 


4.1 [12] 


M 





M 


GAP.N.1 5 


Alerting 


4.1 [12] 


IV! 


M 


M 


GAP.N.1 6 


ZAP (see note 2) 


4.1 [12] 


M 








GAP.N.17 


Encryption activation FT initiated 


4.1 [12] 


IV! 


M 


M 


GAP.N.18 


Subscription registration procedure on-air 


4.1 [12] 


M 


M 


M 


GAP.N.19 


Link control 


4.1 [12] 


IV! 


IVI 


IVI 


GAP. N. 20 


Terminate access rights FT initiated (see note 2) 


4.1 [12] 


M 


M 





GAP.N.21 


Partial release 


4.1 [12] 











GAP.N.22 


Go to DTIVIF (infinite tone length) 


4.1 [12] 











GAP.N.23 


Go to Pulse 


4.1 [12] 











GAP.N.24 


Signalling of display characters 


4.1 [12] 











GAP.N.25 


Display control characters 


4.1 [12] 
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Feature supported 





Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


R/B 


p 


fiAP N 2fi 


Ai ithpntipfltinn nf FT 


4.1 [12] 










GAP N 27 


Fnrrvntinn artivatinn PT initiatpd 


4.1 [12] 











GAP.N.28 


Encryption deactivation FT initiated 


4.1 [12] 











GAP.N.29 


Encryption deactivation PT initiated 


4.1 [12] 











GAP.N.30 


Galling Line Identification Presentation (CLIP) 


4.1 [12] 


M 


M 


M 


GAP.N.31 


Internal call 


4.1 [12] 


M 


M 


M 


GAP.N.32 


Service call 


4.1 [12] 











GAP. N. 33 


Enhanced U- plane connection 


4.1 [12] 











GAP. N. 34 


Galling Name Identification Presentation (CNIP) 


4.1 [12] 


M 


M 


M 


GAP.N.35 


Enhanced security 


4.1 [12] 


M 


IVI 


IVI 



C301 : IF the PT is a headset PP THEN "M" ELSE "I". 



NOTE 1 : The PT is only required to be able to send the «MULTI-KEYPAD» information element containing the 

DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 

and the FT is required to be able to understand it in the public environment. 
NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 

handsets that operates in a system. The invocation of the feature is however optional to the operator. 
NOTE 3: The PT is required to be able to send the «I\/IULTI-KEYPAD» information element containing the DECT 

standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 

automatic access to secondary or alternative networl<s. 
NOTE 4: This feature uses keypad code 1 5 hex. 

NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 
supports it there may be no corresponding action that the FT can \ake with the local network as a result of 

this function. 

NOTE 6: If the feature is not supported on FT side, the FT shall however implement the "sending negative 
acknowledgement" procedure (see clause 7.4.3.4). 

NOTE 7: All procedures of NG1 .N.6 and NG1 .N.7 shall apply to all FTs and for all line types (full parallel call 

compliant lines and DCIBS lines). For DGIBS lines, the FT shall implement in addition NG1.N.22 feature, 
which describes some amendments to NG1.N.6 and NG1 .N.7 for such lines. A given FT shall be 

designed to handle both line types, or only one of them. 



6.5 Data Link Control (DLC) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following DLC services. 



Table 4: DLC services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.D.1 


LU1 Transparent Unprotected service (TRUP) Class 
/minimum_delay 


5.3 [21] 


M 


M 


M 


NG1.D.2 


LU1 Transparent Unprotected service (TRUP) Class 


5.3 [21] 


C401 


C401 


C401 


NG1.D.3 


LU7 64 kbit/s protected bearer service 


5.3 [21] 


C401 


C401 


C401 


NG1.D.4 


LU 12 Unprotected Framed service (UNF) Class 


5.3 [21] 


C401 


C401 


C401 


NG1.D.5 


FU1 DLC frame 


5.3 [21] 


M 


M 


M 


NG1.D.6 


FU7 DLC frame 


5.3 [21] 


C401 


C401 


C401 


NG1.D.7 


FU12 DLC frame with adaptation for codec G. 729.1 


5.3 [21] 


C401 


C401 


C401 


GAP.D.1 


LAPC class A service and Lc 


5.1 [12] 


M 


M 


M 


GAP.D.2 


Cs channel fragmentation and recombination 


5.1 [12] 


M 


M 


M 


GAP.D.3 


Broadcast Lb service 


5.1 [12] 


M 


M 


M 


GAP.D.4 


Intra-cell voluntary connection handover 


5.1 [12] 


M 


C402 


C402 


GAP.D.5 


Intercell voluntary connection handover (see note) 


5.1 [12] 


M 








GAP.D.6 


Encryption activation 


5.1 [12] 


M 


C404 


M 


GAP.D.9 


Encryption deactivation 


5.1 [12] 


C403 


C403 


C403 


C401: 
C402: 
C403: 
C404: 


Status defined by clause 6.3, table 2. 

IF service GAP.M.9 THEN ELSE M. 

IF feature GAP.N.29 OR GAP.N.28 THEN M ELSE 1. 

IF feature GAP.N.17 OR GAP.N.27 THEN M ELSE 1. 
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Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 1 P 


NOTE: 


The PT is required to be able to support tiandover between RFPs. The invocation of the feature is 
however optional to the operator. 



6.6 Medium Access Control (MAC) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following MAC layer 
services. 

Table 5: MAC services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.M.1 


In minimum delay symmetric MAC service type 


5.4 [21] 


M 


M 


M 


NG1.M.2 


lN_normal delay symmetric IVIAC service type 


5.4 [21] 


C501 


C501 


C501 


NG1.M.3 


lpQ_error_detection symmetric MAG service type 


5.4 [21] 


C501 


C501 


C501 


NG1.M.4 


Advanced connections 


5.4 [21] 


M 


M 


M 


NG1.M.5 


"no emission" mode 


5.4 











GAP.M.1 


General 


5.2 [12] 


M 


M 


M 


GAP.M.2 


Continuous broadcast 


5.2 [12] 


M 


M 


M 


GAP.M.3 


Paging broadcast 


5.2 [12] 


M 


M 


M 


GAP.M.4 


Basic connections 


5.2 [12] 


M 


M 


M 


GAP.M.5 


Cs higher layer signalling 


5.2 [12] 


M 


M 


M 


GAP.M.6 


Ouality control 


5.2 [12] 


M 


M 


M 


GAP.M.7 


Encryption activation 


5.2 [12] 


M 


M 


M 


GAP.M.8 


Extended frequency allocation (see note) 


5.2 [12] 


M 








GAP.M.g 


Bearer Handover, intra-cell 


5.2 [12] 


M 


C502 


C502 


GAP.M.10 


Bearer Handover, inter-cell 


5.2 [12] 


M 








GAP.M.11 


Connection Handover, intra-cell 


5.2 [12] 


M 


C503 


C503 


GAP.M.12 


Connection Handover, inter-cell 


5.2 [12] 


M 








GAP.M.13 


SARI support 


5.2 [12] 


M 








GAP.M.14 


Encryption deactivation 


5.2 [12] 


C504 


C504 


C504 


GAP.M.15 


Re-I<eying 


5.2 [12] 


C505 


C505 


C505 


GAP.M.16 


Early encryption 


5.2 [12] 


C506 


C506 


C506 


C501 : Status defined by clause 6.3, table 2. 
C502: IF service GAP.M.1 1 THEN ELSE M. 
C503: IF service GAP.M.9 THEN ELSE M. 

C504: IF feature GAP.N.29 OR N.28 THEN M ELSE 1. 

C505: IF NWK layer procedure "Re-keying during a call" is implemented THEN M ELSE 0. 
C506: IF NWK layer procedure "Early encryption" is implemented THEN M ELSE 0. 


NOTE: Handsets not supporting these extra frequencies need only adapt scanning to allow continued use of the 
standard DECT frequencies. 
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6.7 Physical layer (PHL) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Physical layer 
(PHL) services. 



Table 6: PHL services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.P.1 


2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.2 


Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.P.3 


Physical Packet P64 


5.5 [21] 


M 


M 


M 


NG1.P.4 


Physical Packet P67 


5.5 [21] 











NG1.P.5 


Physical Packet P80 


5.5 [21] 












The requirements of EN 300 444 [12], clause 11 also apply. 

6.8 Speech coding and audio features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Speech 
coding and audio related features. 



Table 7: Speech Coding and audio features 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.SC.1 


G.726 32 kbit/s ADPCM codec 


5.6 [21] 


M 


M 


M 


NG1.SC.2 


G.71 1 84 kbit/s PCM codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.3 


G.722 84 kbit/s 7 kHz wideband codec 


5.6 [21] 


M 


M 


M 


NG1.SC.4 


G.729.1 32 kbit/s 7 kHz wideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.5 


MPEG4 AAC-LD 64 kbit/s 14 kHz supenwideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.6 


MPEG4 AAC-LD 32 kbit/s 1 1 kHz wideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.7 


Packet Loss Concealment (PLC) for G.722 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.8 


Detection of Fax/modem tone 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.9 


Codec selection and switching 


5.6 [21] 


M 


M 


M 


NG1.SC.10 


PP Audio profile type la (classic GAP handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.11 


PP Audio profile type lb (improved GAP handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.12 


PP Audio profile type 1c (HATS 3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1.SC.13 


PP Audio profile type 1d (HATS 3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1.SC.14 


PP Audio profile type 2a (ITU-T Recommendation P.31 1 [i.6] 

7 kHz handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.15 


PP Audio profile type 2b (HATS 7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1.SC.16 


PP Audio profile type 2c (HATS 7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1.SC.17 


PP Audio profile type 3a (HATS 3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.18 


PP Audio profile type 3b (HATS 3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.19 


PP Audio profile type 4a (HATS 7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.20 


PP Audio profile type 4b (HATS 7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.21 


PP Audio profile type 5a supenwideband (14 kHz) handset 


5.6 [21] 


C704 


N/A 


N/A 


NG1.SC.22 


PP Audio profile type 5b supenwideband (14 kHz) handsfree 


5.6 [21] 


C705 


N/A 


N/A 


NG1.SC.23 


FP Audio type 1 b (new ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1.SC.24 


PP echo canceller for FP, narrowband 


5.6 [21] 


N/A 


G707 


G707 


NG1.SC.25 


PP echo supressor for FP, narrowband 


5.6 [211 


N/A 


C707 


G707 


NG1.SC.26 


FP Audio type 2 (analog PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1.SC.27 


FP Audio type 3 (VoIP 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1.SC.28 


FP Audio type 4 (ISDN wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1.SG.29 


FP Audio type 5 (VoIP wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1.SG.30 


PP echo canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 
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Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.SC.31 


PP echo supressor for FP, wideband 


5.6 [21] 


N/A 


G709 


G709 


NG1.SC.32 


PR Audio type 6a (internal call) 


5.6 [21] 


N/A 


M 


M 


NG1.SC.33 


FP Audio type 6b (internal conference) 


5.6 [21] 


N/A 








NG1.SC.34 


Adaptive volume control for FP 


5.6 [21] 


N/A 








C701 : Status defined by clause 6.3, table 2. 



C702: At least one should be provided. G703:At least one should be provided. C704:IF Service NG1 .5 

(Superwideband) THEN M ELSE I. 
G705: IF Service NG1 .5 (Superwideband) THEN O ELSE I. 
G706: At least one should be provided. 

G707: IF feature NG1 .SG.23 (FP type 1 b) OR NG1 .SG.27 (FP type 3) THEN O ELSE I. Either NG1 .SG.24 or 

NG1 .SC.25 may be provided, but not both at the same time. 
G708: At least one should be provided. 

G709: IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN O ELSE I. Either NG1 .SC.30 or 
NG1 .SG.31 may be provided, but not both at the same time. 



NOTE 1: Testing specification for audio features, including handsfree, is provided in EN 300 176-2 [10]. 

NOTE 2: PP types Ic, Id, 2b and 2c are based on HATS methodology. This methodology provides objective test 
results more consistent with subjective tests compared to artificial ear methodology. 

NOTE 3: All audio types used in the present document are compatible with VoIP or long delay networks. 



6.9 Application features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Application 
features. 



Table 8: Application features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


R/B 


P 


NG1.A.1 


Easy PIN code registration 


5.7 


M 





N/A 


NG1.A.2 


Easy pairing registration 


5.7 


M 


M 


N/A 


NG1.A.3 


Handset locator 


5.7 


M 








GAP.A.1 


AC_bitstring_mapping 


4.2 [12] 


M 


M 


M 


GAP.A.2 


Multiple subscription registration 


4.2 [12] 


M 


N/A 


N/A 


GAP.A.3 


Manual entry of the PARK 


4.2 [12] 





N/A 


N/A 


GAP.A.4 


Terminal identity number assignment in mono cell system 


4.2 [12] 


M 


M 


N/A 



ETSI 



35 ETSI TS 1 02 527-3 V1 .2.1 (201 0-04) 

6.10 Network (NWK) feature to procedure mapping 

The NWK features to procedure mapping of EN 300 444 [12] (GAP), clause 6.7 with the following changes and 
additional features shall apply. 



Table 9: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.N.1 Codec Negotiation 




5.2 [21] 


M 


M 


M 


Exchange of codec list during registration 
and location registration 


7.3.1 [21] 


M 


M 


M 


Basic service wideband speech and 
default attributes 


7.3.2 [21] 


M 


M 


M 


Codec Negotiation during call 
establishment 


7.3.3 [21] 


M 


M 


M 


NG1 .N.2 Codec Switching 




5.2 [21] 


M 


M 


M 


Codec Change 


7.3.4 [21] 


M 


M 


M 


Slot type modification 


7.3.5 [21] 


M 


M 


M 


MAC layer advanced connection slot type 
modification 


7.6.7 [21] 








MAC layer connection type modification: 
basic to/from advanced 


7.6.6 [21] 


M 


M 


M 


NG1.N.3 IVIissed call notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Missed call notification 


7.4.1.3 


M 


M 


M 


NG1 .N.4 Voice message waiting 
notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Voice message waiting notification 


7.4.1.2 


M 


M 


M 


NG1.N.5 Date and Time 
synchronization 




5.2 


M 


M 


M 


Date and Time synchronization 


7.4.2 


M 


M 


M 


NG1.N.6 Parallel Calls 




5.2 


M 


M, 
note 2 





Parallel call common requirements 


7.4.3.1 


M 


M 


M 


Control messages 


7.4.3.2 


M 


M 


M 


Sending Keypad information 


8.10 [12] 


M 


M 


M 


Codec change for parallel calls 


7.4.3.3 


M 


M 


M 


Sending negative acknowledgement 


7.4.3.4 


M 


M 


M 


Busy system or line notification 


7.4.8.3 


M 


M 


M 


NG1.N.7 Common parallel call 
procedures (external or internal) 




5.2 


M 


M, 
note 2 





Outgoing parallel call initiation (external 

or internal) 


7.4.3.5.1 


M 


M 


M 


Call waiting indication (external or 
internal) 


7.4.3.5.2 


M 


M 


M 


Call toggle (external or internal) 


7.4.3.5.3 


M 


M 


M 


Call release and call release rejection 


7.4.3.5.4 


M 


M 


M 












Call waiting acceptation (from PR to FP) 


7.4.3.5.6 


M 


M 


M 


Call waiting rejection (from PP to FP) 


7.4.3.5.7 


M 


M 


M 


Active call release with replacement (from 
PP to FP) 


7.4.3.5.12 





M 


M 


Putting a call on-hold 


7.4.3.5.8 





M 


M 


Resuming a call put on-hold 


7.4.3.5.9 





M 


M 


CLIP on call waiting indication 


7.4.3.5.10 


M 


M 


M 


CNIP on call waiting indication 


7.4.3.5.11 


M 


M 


M 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


Hid 


n 
r 


NG1 .N.8 Call transfer (external or 
internal) 




O.d 


M 


M 





Announced call transfer 


7.4.3.6.1 


M 


M 


M 


Unannounced call transfer 


7.4.3.6.2 


M 


M 


M 


Call re-injection to the system (external or 
internal) 


7.4.3.6.3 


M 


M 


M 


Remote party CLIP on call transfer 


7.4.3.6.4 


M 


M 


M 


Remote party CNIP on call transfer 


7.4.3.6.5 


M 


M 


M 


NG1 .N.9 3-party conference call 
(external or internal) 




5.2 





0, 
note 1 


0, 
note 1 


3-party Conference with established 
internal and external calls 


7.4.3.7 


M 


M 


M 


NG1.N.10 Intrusion call 




5.2 


O 


o, 

note 1 


o, 

note 1 


Implicit intrusion call into a line in "single 
call moue 


/.4.O.O. 1 


O901 


M 


IVI 


Explicit intrusion call (from PR to FP) 


7.4.3.8.2 


C901 


IVI 


IVI 


NG1.N.11 Call deflection (internal 
or external) 






U 


0, 
note 1 


0, 
note 1 


Call deflection (internal) 




M 


M 


M 


Call deflection (external) 


7.4.4.2 


M 


M 


M 


Call deflection control messages 


7 AAA A 


M 


M 


M 


NG1.N.12 Line identification 




5.2 


M 


M 


M 


Line identification general requirements 


7.4.5.1 


M 


M 


M 


General line identification requirements 

for external outgoing calls 


7.4.5.2.1 


M 


M 


M 


Line identification for a first external 
outgoing call using «CALL-INFO» IE 


7.4.5.2.2 


M 


M 


M 


Line identification for a first external 
outgoing call using «MULTI-KEYPAD» 
IE 


7.4.5.2.3 





M 


M 


FP managed line selection for a first 
external outgoing call 


7.4.5.2.4 


M 


M 


M 


General line identification requirements 
for external incoming calls 


7.4.5.3.1 


M 


M 


M 


Line identification for a first external 
incoming call 


7.4.5.3.2 


M 


M 


M 


NG1.N.13Call identification 






M 


M 


M 


; ; 

Call identifier general requirements 


/ .4.0.1 


M 


M 


M 


Call identifier assignment on outgoing call 
(rr to rr) 


7.4.6.2 


M 


M 


M 


Call identifier assignment on incoming 
call (FP to PP) 


1 A a n 
/ .4.D.O 


M 


M 


M 


Call status indication to the handset 


1 A a. A 
/ .4.D.4 


IVI 


M 


M 


NG1.N.14 Multiple lines 




5.2 


M 








Multiple lines common requirements 


7.4.7.1 


M 


M 


M 


Terminal attachment and line settings 


7.4.7.2 


M 


M 


M 


Incoming and outgoing external calls on a 

multiple line system 


7.4.7.3 


M 


M 


M 


Internal calls in multiple line context 


7.4.7.4 


M 


M 


M 


Compatibility with non multiple line PP or 
FP 


7.4.7.5 


M 


M 


M 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 




P 


INVj 1 .IN. 1 IVIUIlipic Ocllla 






IVI 


IVI 


Ci 
\J 




iviuiiipiu odiib yuiifcJidi ryL]uirui iitJi lib 


7 4 R 1 


IVI 


IVI 


IVI 




incoming ana ouigoing exTernai cans on a 

mi iltir\lo refill lino 

lilUlll|JlC LfClll III ic 


7 /I Q 


IVI 


IVI 


IVI 




Ri iQ\/ cx/ctom nr lino nntifir'atinn 
DUoy oyoidii \ji iiiic 1 lULi iiuciLiui 1 


7 4 ft 


M 


M 


M 








M 


M 


o 




(^pnpral pnnQirlpr^^tinnQ 
vj^ci ici di ovji loiud diiLfi lo 


7.4.1 0.1 


M 


M 


M 




1 ict r'hannp notifir'atirin 

1— lol Lfl Idl C 1 lUll 1 ILidllUI I 


7 4. 1 n 9 


n 


M 


M 




Oldl I / CI ILI OCOOKJI 1 \\ l\J\XS ""Tf 


7.4.10.4.1 


IVI 


M 


IVI 




Oi ipr\/ Qi innnrtpH pntrx/ fiplHc /nntp 
'^j/uci y ouppui icu CI 1 Li y i icilio ^i idlc 


7.4.1 0.4.2 




IVI 


M 




Read entries (note 4) 


7.4.10.4.3 


M 


IVI 


IVI 




tail eniry ^noie 


"7/1 1 n /i /I 


^/l 

IVI 


M 


IVI 




Save entry (note 4) 


7.4.10.4.5 


IVI 


^ /I 
IVI 


M 




Delete entry (note 4) 


"7/1 -1 r\ yl C 

/.4.1U.4.b 


M 


M 


U 




Delete list (note 4) 


7/1 i n /I 7 


M 


IVI 


M 




Search entries (note 4) 


1 A. \ U.4.0 


M 


M 


M 




Negative acknowledgement 


"7/1 H r» /I n 

/ .4.1 u.4.y 


M 


M 


IVI 




Data packet / Data packet last 


"7/1 H r\ /I H r» 
/.4. ID. 4. ID 


M 


M 


IVI 




DECT system and line settings 

CUIIblUcldllUrib 


/.4. 1 1 .1 


IVI 


M 


u 




inTeraciions Deiween regisiraiion, 

at+ar^hmpnt r»f hanHcptc anH lictc 
dlLdOi 11 1 ici IL ui 1 Idl iLiocLo di iLi Nolo 


7/1-1-10 


IVI 


IVI 






FipIHq HpQrrintinri 

nidUO UCoLrl l|JLIUI 1 


7.4.10.5.1 


M 


M 


M 




rSuDDorted listsi 












List of supported lists 


7.4.10.5.2 





M 


M 




Missed calls list 


7.4.10.5.3 


IVI 


IVI 


M 




Outgoing calls list 


7.4.10.5.4 













Incoming accepted calls list 


7.4.10.5.5 


M 


M 


M 




All calls list 


7.4.10.5.6 













Contact list 


7.4.10.5.7 


IVI 


IVI 


IVI 




Internal names list 


7.4.10.5.8 


M 


M 


M 




All Incoming calls list 


7.4.10.5.11 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


p 




nFf^T Qv^tpm <;pttinn^ li<;t 


7.4.1 1 .3 


M 


M 


o 




1 inp QPttinriQ liQt 

1— 11 IC OdLli Ivjo lloL 


7.4.1 1 .4 


M 


M 


o 




\/irti lal rTintar't lict anH r'all lict nor lino 

VII lUCtl OUI ILClLrL lloL Ctl lU UClll lloL |JC7l III IC 


7 4 1 1 






a 
\j 
















f^iirrpnt PIM phHp 

\J\J 1 1 C7i 1 1 r 1 1 N LrkJUC 


7.4.1 1 .3.1 


M 


M 






Olnpk maQtor 

OHJOix llldoLC?! 


7.4.1 1 .3.2 


M 


M 








7 4 11 T 

/ 1 1 .O.O 


IVI 


IVI 






FP IP arlrlrocc / t\/no 
11 11 ciuui coo / LyjJt; 


7 4 11 9 4 

/.H.I 1 .O 


n 









FP IP pHrlrPQQ / \/aliip 
1 \ in ciuuicoo / vdiuc 


7.4.1 1 .3.5 


n 


n 


n 




FP IP arlrlrPQQ / Qiihnpt maQk 
r r II duui Coo / ouuiid ii icioiv 


7.4.1 1 .3.6 






o 




FP IP arlrlfpcc / natp\A/a\/ 
rr ii ciuuiuoo/ yciicvvciy 


7 4 11 "^7 

/ .H-. 1 1 .O . / 


n 




o 




pp IP arlrlrPQQ / HM*^ cpn/pr 


7 4 11 T R 

/ .t. 1 1 .O.O 










pp x/prQinn / Pirmwarp x/PCQinn 
ii vcioiuii / i^ii 1 1 ivvdi c vcioiuii 


7.4.1 1 .3.9 


M 


M 






1^1 VClOlL'll / ^^|.^IUIII VCl Olwl 1 


7.4.1 1 .3.10 


M 


M 






FP \/prcinn / 1— larH\A/3rp \/prcinn 
II vuioiuii / nctiuvvctic vd oiLfi 1 


7 4 11 9 11 

/ 1 1 .O. 1 1 




n 






Fmiccinn moHo 
^lllloolUII IIIUUC 


7 4 11 9 19 

/ 1 1 .O. 1 ^ 






o 




Npw pin pnHp 


7.4.1 1 .3.13 


M 


M 


o 




r^iinnnrtpH linp QPttinn^l 

|[wU^^V^I ICU IIIIC OdllllUOJ 












1 inp namp 
1— II lU 1 idi 1 It; 


7 4 11 4 1 

/ .t. 1 1 .H. 1 


IVI 


IVI 






1 inp iH 

l_|[ IKi iKJ 


7 4 11 4 9 


IVI 


M 






AttaphprI hanrlQPtQ 

rALlClUl ICU 1 Idl lUoClo 


7.4.1 1 .4.3 


IVI 


IVI 







niallinn nrpfiv 

L/IO-IIIIIM k/IC^IlA 


7.4.1 1 .4.4 


o 


n 


n 




FP mplnrlu 
I I II ici uu y 


7.4.1 1 .4.5 










FP \/nli imp 
1 1 vuiui 1 It; 


7 4 11 4 R 












RlnrkpH niimhpr 


7.4.1 1 .4.7 







n 




h^iiltinlo nallc mriHo ^cinnlo/mi iltinloA 
lvlUILI|JlC OdllO IIIUUC ^oll ly IC/ 1 1 lUI Li|jicy 


7 4 11 4 R 

/ .t. 1 1 .t.O 


IVI 


IVI 


IVI 




Intriicinn f*all 

IIILlUolUIl Udll 


7 4 11 4 Q 










Pprmanpnt PI IR 
1 cl 1 1 Idl lt;l IL '*_/l_in 


7.4. 11 .4.10 






\_/3UO 




Oall fnnA/arHinn 1 InrTinHitinnal 

Odil lUIVVdlUMIU LJI lUUI lUI LIUI Idl 


7.4.11.4.11 


IVI 


M 


1 




Call fonwarding on No Answer 


7.4.11.4.12 


M 


IVI 


1 
1 




od.li lurwdruiiiy uri DUby buuboriijcr 


7.4.1 1 .4.13 


IVI 


M 


1 


NG1 .N.1 7 Calling line identity 




5.2 





U 


U 


resiriciion 


Considerations 


7.4.1 ^:.1 


M 


M 







Pernnanent CLIR mode (all calls) 


7.4.12.2 


M 


M 







— r~ /-> 1 1 1 / III 1 1 \ 

Temporary CLIR mode (call by call) 


7.4.12.3 


IVI 


N/A 





NG1.N.18 Call forwarding 




5.2 


M 


M 


1 


(external calls) 


Call Forwarding common requirements 


7.4.13.1 


M 


M 


1 




External Call Forwarding Unconditional 
(CFU) to external number 


7.4.13.2 


M 


M 


1 




External Call Forwarding on No Answer 

(CFNA) to external number 


7.4.13.3 


M 


M 


1 




External Call Forwarding on Busy 
subscriber (CFB) to external number 


7.4.13.4 


M 


M 


1 


NG1.N.19 DTMF handling 




5.2 


M 


M 


o 




Uplink DTMF transmission at call setup 
when FP connected to classic switching 

network 


7.4.14.1 .1 


M 


C906 


C906 




upiinK u 1 Mr transmission wnen 
connected 




IVI 


M 







Downlink DTMF reception 


7.4.14.2 


M 


M 







Local DTMF feedback of dialled digits 


7.4.14.3 


M 


M 





NG1 .N.20 Tones provision 




5.2 


M 


M 







General considerations 


7.4.15.1 


M 


M 







Tones provision by the system 


7.4.15.2 


M 


M 







Transparency to tones provision by the 
network or PABX 


7.4.15.3 


M 


M 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.N.21 Headset management 




5.2 


C907 


M 


r\ 
U 


Headset considsrations 


/.4.1 b.1 


oyu/ 


M 





Headset call interception 


7.4.16.2 


C907 


M 





Headset incoming call 


7.4.16.3 


C907 


M 





Re-dial of last outgoing call 


7.4.16.4 


C908 


M 





Re-dial of last incoming call 


7.4.16.5 


C908 


M 





Switching from headset to handset 
(headset initiated) 


7.4.16.6 


C908 


M 





Switching from headset to handset 
(handset initiated) 


7.4.16.7 


C909 


M 





Compatibility with other telephony 
features and profiles 


7.4.16.8 


C907 


M 





NG1 .N.22 Handling of lines where 
second calls are signalled In-band 




5.2 


M 



note 2 





General requirements 


7.4.3.10.1 


1 


M 


M 


Basic 'double call with in-band signalling' 
lines 


7.4.3.10.2 


1 


M 
note 3 


M 


Off-hook CLIP enabled 'double call with 
in-band signalling' lines 


7.4.3.10.3 


M 


M 
note 3 


M 


Use of transparent commands on DCIBS 

llllcb ^DdolL Ul V^M-ilUUI\ \jl-\r cilcLUIcUj Ui 
di ly LfLi ici iiiic 


"7 /I O H A /I 

/.4.0.1U.4 


M 


M 


M 


GAP. N. 11 Location registration 




4 1 ri ?i 

1. 1 [ I^J 


M 




M 


1 rtr'Qtif^n ronictratinn 
1— L/Lfdiiui 1 1 loLI ClllUI 1 




IVI 


M 


M 


1 nr'atinn i inrlatp 


8 9Q n 91 


M 






Xprminal r^anahilitu inrlir'atinn 

1 C?l 1 1 III ICll V-ZCtlJCtUIIILy 1 1 lUILfCtllUI 1 


7.4.9.1 


M 


M 


M 


indication/assignment 




4 1 ri9i 


M 




M 


WULdllllliy d^L-coo IILJIILo 


o.ou 1 1 ^ 1 


IVI 


M 


M 


Tprminpl f~^^^n^^hiilit\/ inrlip^itinn 
loiiiiiiidi od|Jduiiii.y iiiuioduuii 


7.4.9.1 


M 


M 


M 


Ai ithontir'atinn nf PX 


R 94 n 91 


M 


M 


M 


GAP.N.16ZAP 




1 [ 1 


M 


o 




Ohtaininn arr'occ rinhtc 
wuidniiiiy dLfLft;oo iiyiiio 


R 9n n 91 


IVI 


M 


M 


Xorminal f^anahilitu inHir'atinn 
1 CI 1 1 III idi wd|JduiiiLy II iLJiLfdLiui i 


8 1 7 n 91 

O.I / [1 


M 


M 


M 


IMOI CI 1 ICI llll lU {.lie VdlUC 


8 9R n 91 


M 


M 


M 


Xprminal riflnflhilitv inHipfltinn 

1 CI 1 1 III Idl Od|JdLJIIILy II ILIIOdLIUI 1 


7.4.9.1 


M 


M 


M 


registration user procedure on-air 




4 1 ri9i 


IVI 


M 


M 


Ohtflininn flpfPQQ rinhtc 

wULdll III ly dOLrCoO iiyiiLo 


8 "^n n 91 


M 


M 


M 


Xprminfll riflnflhilitv inHipfltinn 

1 CI 1 1 III Idl Od|JdUIIILy II ILIILrdLltJI 1 


7.4.9.1 


M 


M 


M 


RAP N 1Q 1 ink rnntrnl 

VJIAAI^ .IN. 1 <7 l_l 1 lr\ LrUI 1 LI U 1 




4 1 ri9i 


M 


M 


M 


II lUI 1 11 11 11 Lldlc^U 1 11 H\ c;oldUlloi 11 1 lc;l 1 L 


7 R r91 1 

/ .O.O 1 J 


IVI 


M 


M 


nirpot PX initiptpH link PQt^ihiiQhmpnt 

L^IICL>L I 1 llllLldLCVJ IlllrX CoLdUllollllldIL 


R Sfi n 91 

O . vJU 11^1 


M 


M 


M 


1 ink fPlppQP "nnrmpl" 
i_iiii\ ic;ic7doc7 iiuiiiidi 


R ^7 n 91 


M 


M 


M 


1 ink rpjpaQP "ahnnrmal" 
i_iiir\ icic^doc^ dk^iiuiiiidi 


R "^8 n 91 


M 


M 


M 


1 ink rpjpscp "maintain" 
i_ii ir\ 1 ti^icdoc iiidiiiLdiii 


R "^Q n 91 


IVI 


M 


M 


GAP. N. 24 Signalling of display 
characters 




4 1 ri9i 




o 




nicnlax/ 
L-zioiJidy 


8 1 R n 91 


M 


M 


M 


Xprminal panahilitv/ inHi/^atirtn 
iciiiiiiidi Lrd|JdL/iii ly II luiLrdiiLfi 1 


7.4.9.1 


M 


M 


M 


GAP. N. 25 Display control 
characters 




4 1 ri9i 


n 








nicnlav 
L-/iouiciy 


8.16 [12] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.31 Internal Call 




4.1 [12] 


M 


M 


M 


Internal call setup 


7.3.6 [21] 


M 


M 


M 


Internal call keypad 


8.19 [12] 


M 








Internal call CLIP 


8.43 [12] 


M 


M 


M 


Internal call GNIP 


8.44 [12] 


M 


M 


M 


Internal call codec priority 


7.4.3.9 


M 


M 


M 


UTF-8 CNIP 


7.4.17 


M 


M 


M 
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Status 


Feature 


Procedure 


Reference 


PT 


FT 




p 


GAP. N.34 Calling Name 
Idpntlfif atinn Prp<;pntatinn /^ONIP^ 






IVI 


IVI 


IVI 


Oallinn Mamo IrlontificQtiAn ProcontatiAn 
Ociiiiiiy iNciiiit; lUUi lUiiOclLitJi 1 r I coci ilclLitJi 1 

(CNIP) Indication 


R 49 n 91 


IVI 


IVI 


IVI 


UTF-8 CNIP 


7.4.17 


M 


M 


M 


GAP.N.35 Enhanced security 




4.1 [12] 


IVI 


IVI 


IVI 


Encryption of all calls 


8.45.1 [12] 


IVI 


IVI 


IVI 


Re-I<eying during a call 


8.45.2 [12] 











Early encryption 


8.45.3 [12] 











Subscription requirements 


8.45.4 [12] 


IVI 


IVI 


IVI 


Behaviour against legacy devices 


8.45.5 [12] 


M 


M 


M 



C901 : At least one of the two procedures 7.4.3.8.1 OR 7.4.3.8.2 shall be implemented. 
C902: IF NG1 .N.14 THEN "O" ELSE "I". 
C903: IF NG1 .M.5 THEN "M" ELSE "I". 
G904: IF NG1.N.10 THEN "M" ELSE "1". 
G905: IF NG1 .N.I 7 THEN "M" ELSE "I". 

C906: IF FP is connected to classic switching networks (PSTN for example) THEN "M" ELSE "N/A". 
G907: IF the PT is a headset PR THEN "M" ELSE "I". 
G908: IF the PT is a headset PR THEN "O" ELSE "I". 

G909: IF the PT is a headset PP THEN "I" ELSE "O". 

NOTE 1 : If the corresponding feature is not supported on FT side, the FT shall however implement the "sending 

negative acknowledgement" procedure (see clause 7.4.3.4). 
NOTE 2: All procedures of NG1 .N.6 and NG1 .N.7 shall apply to all FTs and for all line types (full parallel call 

compliant lines and DCIBS lines). For DCIBS lines, the FT shall implement in addition NG1.N.22 feature, 

which describes some amendments to NG1 .N.6 and NG1 .N.7 for such lines. A given FT shall be 

designed to handle both line types, or only one of them. 
NOTE 3: Both procedures are M for the FP. However, for a given line, only one of the procedures 7.4.3.1 0.2 or 

7.4.3.10.3 is used. 

NOTE 4: See also clause 7.4.1 0.4 for details per list. 
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6.1 1 Data Link Control (DLC) Service to procedure mapping 

The DLC service to procedure mapping of EN 300 444 [12] (GAP), clause 6.8.1, with the following changes and 
additional services shall apply. 



Table 10: DLC service to procedure mapping 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.D.1 LU1 Transparent 
Unprotected service (TRUP) 
Class 0/minimum_delay 




5.3 [12] 


M 


M 


M 


LU1 Transparent Unprotected service 
(TRUP) operation 


1 1 .2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


Minimum delay (speech) operation 


14.2.3 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1.D.2 LU1 Transparent 
Unprotected service (TRUP) 
Class 




5.3 [21] 


C1001 


C1001 


C1001 


LU1 Transparent Unprotected service 

(TRUP) operation 


1 1 .2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1 .D.3 LU7 64 kbWs protected 
bearer service 




5.3 [21] 


C1001 


C1001 


C1001 


LU7 DLC layer service 


1 1 .9.4 [4] 


M 


M 


M 


NG1 .D.4 LU12 LU 12 Unprotected 
Framed service (UNF) Class 




5.3 [12] 


C1001 


C1001 


C1001 


LU12 UNprotected Framed service (UNF) 

operation 


11.14 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1.D.5 FU1 DLC frame 




5.3 [12] 


M 


M 


M 


FU1 frame operation 


8.19 [12] 


M 


M 


M 


FU1 frame structure 


12.2 [4] 


M 


M 


M 


NG1.D.6 FU7 DLC frame 




5.3 [12] 


C1001 


C1001 


C1001 


FU7 frame structure 


1 1 .9.4.2 [4] 


M 


M 


M 


NG1 .D.7 FU12 DLC frame witfn 
adaptation for codec G.729.1 




5.3 [12] 


C1001 


C1001 


C1001 


FU12 frame structure 


12.12 [4] 


M 


M 


M 


Annex for codec G.729.1 


E.I [4] 


M 


M 


M 


FU12 frame operation 


7.5.2 [12] 


M 


M 


M 


CI 001 : Status defined by clause 6.3, table 2. 
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6.12 Medium Access Control (MAC) service to procedure 
mapping 

The MAC service to procedure mapping of EN 300 444 (GAP) [12], clause 6.8.2, with the following changes and 
additional services shall apply. 



Table 11 : MAC service to procedure mapping 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.M.1 lN_minimum delay 
symmetric MAC service type 




5.4 [21] 


M 


M 


M 


MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_minimum delay symmetric MAC service, 
type 1 


5.6.2.1 [3] 


M 


M 


M 


NG1 .M.2 lN_normal delay 
symmetric MAC service type 




5.4 [21] 











MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_normal delay symmetric MAC service 
type 2 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.3 lpQ_error_detection 
symmetric MAC service type 




5.4 [21] 











MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lp_error_detection symmetric MAC service 
type 3 


5.6.2.1 [3] 


M 


M 


M 


Single-subfield protected format 


6.2.1.3.4 [3] 


M 


M 


M 
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Service/Procedure mapping 





Status 


Service 


Procedure 


Reference 


PT 


FT 


K/D 


□ 
r 


NG1 .M.4 Advanced connections 




0.4 [^1 J 


M 


^y1 
IVI 


M 


— — — — : — 

Setup of advanced connection, bearer 




M 


IVI 


M 


Connection type modification: basic to/from 
auvanceu 


7.6.6 [21] 


M 


r yi 
IVI 


M 


Slot type modification 


7.6.7 [21] 


M 


IVI 


M 


Service type modification 


7 C Q rO i 1 


Ol 1 Ul 




L/1 1 Ul 


ECN number modification 


"7 c ri roH 1 
/.D.y 




\j \ \ Kid. 


01 1 


Connection/bearer release 


"7 c ^ r\ roH i 
/.b.10 


M 


M 


M 


NG1 .M.5 "no-emision" mode 




5.4 











Tail identification for "no emission" mode 


7.1.2 [3] 


M 


M 


M 


Extended Physical and Mac layer 
capabilities (part 2) bit a23 


7.2.3.11 [3] 


M 


M 


M 


Bearer handover/replacement information, 

nfi 1 iltiTKonfiQ nm int^n\ii/n 


1 .i.A.6 [oj 


M 


r yi 
IVI 


M 


ilu f^llllbblUll ITIUUU byflO lilluriilctUUil 


7 o c q rqi 

/ .0.0.0 [Oj 


IVI 


IVI 


r/i 

IVI 


no emission moae proceaures 


9.4 \6\ 


IVI 


M 


M 


Management procedures for "no emission" 
mode 


11.11 [3] 


M 


r yi 
IVI 


M 


VJIMr .Ivl.^ VurUIUIilUUUb UrUdUOdoL 






IVI 


M 


M 


Downlink broadcast 


7.6.3 


M 


IVI 


M 


Higher Layer information FP broadcast 


"7 /I n o 


IVI 


r yi 
IVI 


^ /I 
IVI 


GAP.M.3 Paging broadcast 




5.2 [12] 


M 


M 


M 


Paging broadcast 


7.6.4 [21] 


M 


M 


M 












GAP.IVI.9 Bearer tiandover, 
intra-cell 




5.2 [12] 


M 


C1 103 


C1 103 


Bearer handover request 


7.6.11 [21] 


M 


M 


M 


GAP.M.10 Bearer handover, 
inter-cell 




5.2 [12] 


M 


O 


O 


Bearer handover request 


"7 o H H ro^ 1 

/.b.l 1 [^1 J 


M 


r yi 
IVI 


M 


GAP.M.11 Connection handover, 
intra-cell 




corn oi 

5.2 [12] 


M 


Ol 1 U4 


\j \ \ U4 


ouruicuuuii iidiiuovcr fcqucoL 


7 R 1 9 r91 1 
/ .O. \c. 1 J 


IVI 


^/l 

IVI 


IVI 


GAP. M. 12 Connection handover, 

intpr-ppll 




c o n 91 


IVI 




n 


Connection handover request 


7.6.12 [21] 


M 


M 


M 


GAP.M.13 SARI support 




5.2 [12] 


M 








Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP. M. 15 Re-keying 




5.2 [12] 


C1 105 


C1 105 


C1 105 


Re-keying 


10.17 [12] 


M 


M 


M 


GAP.M.16 Early encryption 




5.2 [12] 


C1 106 


C1 106 


C1106 


Early encryption 


10.18 [12] 


M 


M 


M 



C1 101 : IF service NG1 .4 OR NG1 .5 OR NG1 .6 OR NG1 .2 lA II OR NG1 .2 lA III THEN M ELSE O. 

C1 1 02: IF multiple connection between the same PT-FT pair THEN M ELSE O. 

C1 1 03: IF service GAP.M.1 1 THEN O ELSE M. 

C1 1 04: IF service GAP.M.9 THEN O ELSE M. 

C1 1 05: IF NWK layer procedure "Re-keying during a call" is implemented THEN M ELSE O. 

C1 1 06: IF NWK layer procedure "Early encryption" is implemented THEN M ELSE O. 
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6.13 Application feature to procedure mapping 

The Application feature to procedure mapping of EN 300 444 [12J (GAP), clause 6.8.3, with the following changes 
shall apply. 



Table 12: Application feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.A.1 Easy PIN code 
registration 




5.7 


M 





N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Searching mode and PIN code requests 


7.10.1.1.1 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 








N/A 


Registration user feedback 


7.10.1.3.3 


M 





N/A 


NG1 .A.2 Easy pairing registration 




5.7 


M 


M 


N/A 


Easy pairing description 


7.10.1.2.1 


M 


M 


N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Base station limited registration mode 


7.10.1.2.2 


N/A 


M 


N/A 


Searching mode request 


7.10.1.2.3 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 








N/A 


Registration user feedback 


7.10.1.3.3 


M 





N/A 


NG1 .A.3 Handset locator 




5.7 


M 








Handset locator 


7.10.2 


M 


M 





GAP.A.1 AC to bitstring mapping 




4.2 [12] 


M 


C1201 


M 


AC to bitstring mapping 


14.2 [12] 


M 


M 


M 


GAP.A.2 Multiple subscription 
registration 




4.2 [12] 


M 


N/A 


N/A 


Subscription control 


14.1 [12] 


M 


N/A 


N/A 


GAP.A.3 Manual entry of the 
PARK 




4.2 [12] 





N/A 


N/A 


Manual entry of the PARK 


14.3 [12] 


M 


N/A 


N/A 


GAP. A. 4 Terminal identity number 
assignment in mono cell system 




4.2 [12] 


M 


M 


N/A 


Terminal identity number assignment 


14.4 [12] 


M 


M 


N/A 


C1 201 : IF feature GAP.N.9 OR GAP.N.1 OR GAP.N.1 2 OR GAP.N.26 THEN M ELSE N/A. 



6.14 General requirements 

6.1 4.1 Network (NWK) layer message contents 

The requirements of TS 102 527-1 [21], clause 6.14.1 shall apply. 

6.14.2 Transaction identifier 

The requirements of TS 102 527-1 [21], clause 6.14.2 shall apply. 

6.14.3 Length of a Network (NWK) layer message 

The requirements of TS 102 527-1 [21], clause 6.14.3 shall apply. 

6.14.4 Handling of error and exception conditions 

The requirements of TS 102 527-1 [21], clause 6.14.4 shall apply. 

6.14.5 Generic Access Profile (GAP) default setup attributes 

The requirements of TS 102 527-1 [21], clause 6.14.5 shall apply. 
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6.14.6 Coexistence of Mobility Management (MM) and Call Control (CC) 
procedures 

The requirements of TS 102 527-1 [21], clause 6.14.6 shall apply. 

6.14.7 Coding rules for information elements 

The requirements of TS 102 527-1 [21], clause 6.14.7 shall apply. 



7 Procedure description 

The following clauses define the process mandatory procedures which are in the scope of the New Generation DECT 
wideband speech. Each procedure (if appropriate) is divided into three parts: 

a) normal (i.e. successful) case(s). This part defines the functions and respective protocol element values in 
normal operation; 

b) associated procedure(s). This is an integral part of the actual procedure (if defined in the present document), 
i.e. if a procedure is being declared to be supported, the respective entity shall also support the associated 
procedures, e.g. timer management, in the clause following the description of the normal case; 

c) exceptional case(s). This is an integral part of the actual procedure (if defined in the present document), i.e. if a 
procedure is being declared to be supported, the respective entity shall also support the exception handling 
defined in the clause following the description of the normal case. 

All protocol elements listed in the following clauses are process mandatory, i.e. the FT and PT depending on their role 
in the procedure shall send or shall receive and process the relevant protocol elements as listed in the respective tables if 
not exphcitly stated as being optional. 

The primitives used in procedure descriptions are defined only for the purpose of describing layer-to-layer interactions. 
The primitives are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The primitive definitions have no normative significance. 



7.1 Backward compatibility with Generic Access Profile (GAP) 
and with New Generation DECT part 1 (wideband speech) 
equipment 

7.1 .1 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 3 Fixed Parts (FPs) 

The FP shall support the GAP (EN 300 444 [12]) standard procedures (full slot and ITU-T Recommendation 
G.726 [15]). In other words, it shall inter-operate with a GAP compliant PP. 

NOTE 1: The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that GAP compliant PPs may have a more relaxed requirement of TCLw than New 
Generation DECT part 3 devices. In some scenarios, when combining GAP terminals with poor TCLw 
with long delay networks (like VoIP) and insufficient echo cancellation in the network, audible echo 
could be perceived by the far end terminal. This problem is not specific of devices compliant with the 
present document. For more information refer to EN 300 175-8 [8], annex E. 
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7.1 .2 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 3 Portable Parts (PPs) registered 
on GAP compliant FPs 

The PP shall use the GAP standard procedures (full slot and ITU-T Recommendation G.726 [15]) in front of GAP 
standard FP. 

7.1 .3 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 3 Fixed Parts (FPs) 

The FP shall support DECT New Generation part 1 (TS 102 527-1 [21]) procedures. In other words, a DECT New 
Generation, part 3 Fixed part shall operate exactly as a DECT New Generation, part 1 FP for a New Generation Part 1 
PP. All features and services defined in TS 102 527-1 [21] shall be provided. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 

at registration. 

NOTE 2: It should be noted that New Generation DECT part 1 PPs may have a more relaxed requirement of TCLw 
than New Generation DECT part 3 devices. Note 2 of clause 7.1.1 may be also applicable this case. For 
more information refer to EN 300 175-8 [8], annex E. 

7.1 .4 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 3 Portable Parts (PPs) registered 
on NG-DECT Part 1 FPs 

The PP shall use the part 1 standard procedures (TS 102 527-1 [21]) in front of NG-DECT Part 1 FPs. 

7.2 Generic Access Profile (GAP) procedures 

Unless otherwise noted, all procedures defined in EN 300 444 [12] GAP are automatically appUcable to New 
Generation DECT wideband speech. Therefore the present document can be considered an extension of GAP. 

7.3 New Generation DECT; part 1 : Wideband Speech 
procedures 

The present document is defined as an extension of New Generation DECT; part 1: Wideband Speech [21]. 

Unless otherwise noted, all procedures defined in TS 102 527-1 [21] (New Generation DECT; part 1: Wideband 
Speech) are automatically apphcable to New Generation DECT; part 3: Extended Wideband Speech Services. 

The clauses 7.4 to 7.10 describe the additional procedmes specific for New Generation DECT; part 3: Extended 
wideband speech services. 

7.3.1 Implementation examples of part 1 : Wideband Speech specific 
procedures 

For detailed examples of Wideband speech specific procedures, please refer to the informative annex D of 
TS 102 527-1 [21]. 

7.4 Network (NWK) layer procedures specific for part 3 

This clause specifies the additional NWK layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 
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This profile does not prevent any PT or FT from transmitting or receiving and processing any other NWK layer 
message or information element not specified in the profile. A PT or FT receiving an unsupported NWK layer message 
or information element, which it does not recognize, shall ignore it, as specified in EN 300 175-5 [5], clause 17. 

7.4.1 Generic events notification 



7.4.1.1 General 

Equipment supporting New Generation DECT wideband voice shall support the generic events notifications as 
described in this clause. 

Generic events notifications are based on CISS {FACILITY} messages, which contain the information element 
«Events Notification», sent in the direction FT = > PT. 

For the purpose of transmitting the {FACILITY} message containing the «E vents Notification» information element 
to the PT, the FT shall either: 

• use any already established link used by any Connection Oriented service (such as voice, data or service call), 
if existing, or 

• if there is no existing call at the time of sending the {FACILITY} message, use the CLSS procedure as defined 
in clause 10.4.2.3 of EN 300 175-5 [5]. 

The FT shall initiate indirect link establishment as defined in clause 7.3.8 of TS 102 527-1 [21] "Indirect 
FT initiated Unk establishment" procedure. The short and the full format with IPUI are allowed in the 
paging messages. The LCE header shall be set to either; the "000" value (indicating "no U-plane" ) or to 
the "100" value (indicating "General code for voice service"). 

Full slot and long slot (j=640) are allowed as slot type. The chosen slot type (long or full) is decided by 
the initiating party (FT). 

Whatever the {FACILITY} transport mode (CLSS procedure or re-use of akeady established link), the {FACILITY} 
message shall be used with dummy transaction identifier value 6 and the protocol discriminator CISS. 

Direct FP initiated Unk estabUshment is out of the scope of the present document. 

The following requirements apply for the FP and the PP: 

• The FP shall send the "Event type" and "Event sub type" arguments to indicate the kind of event. 

• The PP shall support the "Event multiplicity" argument which should be used to indicate how many 
unconsulted events of the specific type are waiting, regardless of any previous notification. The PP shall be 
capable of handling values up to 16 383. The PP shall ignore events of unknown types or sub-types. 

• It is the responsibility of the FP to ensure that Event status information within the PP is up to date. 
The «CALL-lNFORMAT10N» IE may be present in a notification and is used for indicating: 

the line the notification is relating to (if any); or 

that the notification is relating to all Unes (using "All lines" subtype). 

For notifications relating to a set of Unes (but not aU), the «CALL-INFORMATION» IE shall contain the Ust of 
these Unes. 

NOTE 1 : Notification relating to a set of lines (but not aU) are not used in the present document and are for future 

use. 

Optionally more than one event notification can be included by using the extension bit. In that case: 

• if a «CALL-lNFORMATION» IE is used, each of the notifications sent together shaU relate to the specified 
line, or to All lines', or to a set of lines, as above; 

• if no «CALL-INFORMATION» IE is used, each of the notifications sent together is not related to any line. 



ETSI 



48 ETSI TS 1 02 527-3 V1 .2.1 (201 0-04) 



Table 13: Values used within {FACILITY} message to convey Lineld in notification 



Information element 


Field within tlie information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Call information» 








<ldentifier type> 





Line identifier 


<ldentifier subtype> 


'OO'H, 
'03'H, 
'04'H 


'Line identifier for external call', 
'Relating to', 
or 'All lines' 


<ldentifier value> 


All, except 127 


The line identifier value itself if 
present (e.g. it is absent if 'All lines' 
subtype is used) 

Value 'None' (127) cannot be used 



Notification of an event shall be sent only to relevant PPs. Depending on the event nature, receiving the notification 
may be relevant for one or more PPs, or for one or more lines: 

If not related to a hne but related to one or more PPs, the notification shall be sent by the FP to the concerned 
PP (or PPs) without specifying any line identifier (i.e. without any «CALL-INFORMATION» information 
element). 

EXAMPLE: This is the case for the internal names Ust (see clause 7.4.10.2) and the DECT system settings list 
change notifications if implemented. 

If related to a line, the notification shall be sent by the FP to all registered PPs that are attached to this line with 
a line identifier in a «CALL-INFORMATION» to convey the line concerned by this notification (using 
"Line identifier for external call" or "Relating to" subtype). The FP shall use the "Attached handsets" line 
setting to determine these PPs. 

NOTE 2: A PP may be attached to several lines. 

EXAMPLE 1: This is the case for the "Voice message waiting notification" (see clause 7.4.1.2), or the "Missed 
calls notification" (see clause 7.4.1.3). 

If related to all lines, the notification shall be sent to all registered PPs, with a line identifier subtype set to "AH 
lines" in a «C ALL-INFORM ATION» information element. 

EXAMPLE 2: This may be the case for the contact list, if notification is implemented and the line identifier of the 
modified entry is "AH lines" subtype. 

7.4.1 .2 Voice Message waiting notification 

Upon reception of a voice message waiting indication (MWI) from the network on a dedicated line, the FP shall send to 
any PP attached to this hne, a voice message waiting notification using the generic events notification. 

NOTE 1: The FP is aware of the attached handsets to a line thanks to the line settings list/attached handsets field. 

Voice message waiting notification shall always be sent with a hne identifier using subtype 'Line identifier for external 
call'. 

«Events notification» information element shall be filled with the values specified in table 14. 
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Table 14: Values used within {FACILITY} message for voice message waiting indication activation 



Information element 


FiplH within thp infnrmfition 

I^ICIvl W lllllll IIIC Illli^llllClllvll 


within thp fipld/IE 

will III 1 11 1^ 1 1^1 VI/ I 


ivui II iciti vc o^tiui 1/ ^ui 1 unci 11 


«Events notification» 








<Event type> 





Message waiting 




1 


V UIOC 


<Event multiplicity > 


0..127 


Number of messages, for the 
specified line (see note at this table 
and note 2 after the table) 


«Call lnformation» 








<ldentifier type> 





Line identifier 


<ldentifier sub type> 





Line identifier for external call 


<ldentlfier value> 


All, except 127 


The line identifier value itself 
Value 'None' (127) cannot be used 


NOTE: 'Event multiplicity' can be extended for values up to 16 383. See note at table 39. 



Upon reception of a { FACILITY } message with a content as defined in table 14, the PP shall indicate the Voice MWI 
status to the receiving user. 

Voice message waiting deactivation notification. As soon as the number of messages for a given Une is '0', the FP 
shall then send a 'Voice message waiting notification' to all PPs attached to that line, with an <Event multiplicity> field 
set to '0'. 

NOTE 2: The meaning of this number is network dependent; e.g. it may be the total number of messages in the 
voicemail box, or the total number of unread messages in the voicemail box only. 

NOTE 3: This notification allows the PP to give a hint to the user that the voicemail box does no longer need to be 
consulted for the specified Une. A PP attached to serveral lines could wait until it receives such a 
notification for all Unes it is attached to, before it gives a hint to the user (e.g. switch off an MWI-LED) 

7.4.1 .3 Missed call notification 

A 'missed call notification' is sent by the FP each time any event modifies the 'missed call list'. This most notably 
happens when an external incoming call has not been answered by any of the PPs (an entry was added to the 'missed 
call Ust'). 

The present procedure also specifies the sending of list change indications for the missed call list (see 'Simultaneous 
'list change indication' subsection below). 

Line identifier. An event modifying the 'missed call list' always occurs on, or concern, one of the lines of the system. 
The notification is sent to all PPs attached to that line, and only to them. A 'missed call notification' shall contain a line 
identifier, specified in a «CALL INFORMATION» IE, using the line id subtype 'Line identifier for external call'. 

Line specific event multiplicity. The <event multiplicity> field of the 'missed call notification' shall contain the 
number of 'unread' missed call entries in the 'missed call list' /or the specified line, at the time the notification is sent. 

NOTE 1 : An 'unread' missed call entry is an entry with 'Read status' field set. It corresponds either to a missed call 
that was just added to the missed call hst, or to a missed call that was already in the missed call hst but 
remained 'unread'. 

NOTE 2: The 'Number of calls' field of the missed call list (see clauses 7.4.10.5.1.8 and 7.4.10.5.3) is not taken into 
account when computing the <event multiplicity> field: only entries are computed. 

Simultaneous 'list change indication'. A 'list change indication' for the 'missed call Ust' shall be sent together with the 
'missed caU notification', in the same «Events notification» IE. 

Conversely, a 'list change indication' for the 'missed call Ust' shall never be sent alone, but always along with a 'missed 
call notification'. 

NOTE 3: Missed call subtype '02'H (see EN 300 175-5 [5], clause 7.7.55) is used to indicate that there is not 

actually any new missed call: in that case, the piupose of the accompanying 'missed caU notification' is to 
possibly update the number of 'unread' missed calls on PP side. 
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EXAMPLE 1: In case a 'list change indication' is sent following the reading of an entry by one of the PPs (entry 
read status modified), the accompanying missed call notification indicates the new number of 
'unread' entries. 

EXAMPLE 2: In case a 'list change indication' is sent following the deletion of a 'read' entry, the accompanying 
missed call notification indicates the same number of 'unread' entries (i.e. serves no purpose). 

The <event multiplicity> field of the 'list change indication' shall contain the total number of entries in the 'missed call 
list' /or the specified line, at the time the notification is sent ('unread' plus 'read' missed calls). 

Events triggering the notifications. The following event types shall trigger a 'missed call notification' together with a 
'list change indication' from the FP. For each event type, the line to specify and the set of PPs receiving the notification 
(targeted PP or PPs) are indicated. 

• A new external missed call just arrived (entry added). A 'missed call notification' shall be sent immediately 
after a new external call is missed and has been added to the 'missed call list'. 

Specified line: Line where the missed call occurred. 

Targeted PPs: all PPs attached to the line where the missed call occurred. 

The missed call subtype used shall be 'Ol'H ("A new external missed call just arrived"). 

NOTE 4: Only external missed incoming calls should be added to the "Missed call list" and notified by the FP. 

NOTE 5: When receiving missed call subtype 'Ol'H, the PP should give a hint to the user that the missed call list 
should be consulted (e.g. switching on a dedicated LED). 

NOTE 6: The PP should remove the hint when it received an event multiplicity of 'Q' for each of the lines it is 
attached to. Additionally, the PP could also do so after having consulted the list. 

• Entry modified or deleted (especially: entry 'read'). A 'missed call notification' (see above) shall be sent as 
soon as an entry in the 'missed call list' is modified (especially: 'read', see clause 7.4.10.5.1.5 for the definition 

of a 'read' entry), or deleted. 

Specified line: Line of the entry that was read or deleted. 
Targeted PPs: AH PPs attached to the specified line. 

The missed call subtype used shall be '02'H ("No new missed call arrived, but the number of 'unread' 
external missed voice call has-or may have-changed"). 

• Base reset. In case the FP is reset, a 'missed call notification' shall be sent once for each line. 

Specified line: Line for which the notification is sent (once for each line). 

Targeted PPs: AH PPs attached to the specified line. 

The missed call subtype used shall be '02'H. 

NOTE 7: The purpose of this notification is re-synchronise the PPs with the list state, in case the list has changed 
during the base reset. 

NOTE 8: The 'missed call subtype' 'Ol'H ('A new missed call just arrived') could however be used if the 'base reset' 
is coincidental with the arrival of a brand new missed call, to avoid sending two notifications. 

• Location registration: A 'missed call notification' shall be sent after location registration, once for each line 

the PP is attached to (1 FACILITY message per line the PP is attached to). 

Specified line: Line for which the notification is sent (once for each line the PP is attached to). 
Targeted PP: The PP performing location registration (and only this PP). 
The missed call subtype used shall be '02'H. 
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NOTE 9: A location registration request ({LOCATE-REQUEST} message) is sent by the PP at least when the 

handset is switched on. A location registration request could be sent by the PP when it goes back in range 
(after it got out of range) in order to inform the FP that it may have lost some notifications. 

NOTE 10:The 'missed call subtype' 'Ol'H ('A new missed call just arrived') could however be used if the 'location 

registration' is coincidental with the arrival of a brand new missed call, to avoid sending two notifications. 
But subtype 'Ol'H cannot be used in order to inform the PP of a missed call that arrived when it was 
possibly out of range and that it may have lost (subtype 'Ol'H can only be used at the time when the new 
missed call arrives, and the notification cannot be repeated). 

Almost simultaneous events. Several events concerning the missed call list occurring almost simultaneously may be 
the subject of a single notification, provided the following rules are respected: 

1) all events notified together shall occur on, or concern, the same Une 

2) the events notified together may be of the same type, or of different types (e.g. one entry added for a new 
missed call, another entry modified or deleted) 

3) the common notification shall use missed call subtype 'Ol'H if (and only if) at least one of the events notified 
together is of type 'A new external missed call just arrived (entry added)' 

4) the notified numbers correspond to the state of the missed call list after all the events notified together 
occurred 

NOTE ll:Examples of use of these rules are provided in clause C.2.6. 

« Events notification » information element shall be filled with the values given in table 15. 



Table 15: Values used within {FACILITY} message for missed call notification 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


1 


Missed call 


<Event sub type> 


1 


A new external missed voice call just 
arrived 


<Event multiplicity > 


0...127 


Number of new missed calls in the 
missed call list for the specified line 
(see note 1 ) 


<Event type> 


3 


List change indication 


<Event sub type> 


1 


Missed calls list 


<Event multiplicity > 


All 


Total number of elements in the list 
for the specified line 


«Call lnfornnation» 






(see note 2) 


<ldentifier type> 





Line identifier 


<ldentifier sub typo 





Line identifier for external call 


<ldentifier value> 


All 


The line identifier value itself 


NOTE 1 : 'Event multiplicity' can be extended for values up to 1 6 383. See note at table 39. 
NOTE 2: The «Call information» Information Element is only present if the call is external. 



Upon reception of a {FACILITY} message with a content as defined in table 15, the PP shall indicate the missed call to 
the receiving user. The PP may use the previous calling party information provided with the last incoming call 
presentation. 

After user intervention the PP shall access the missed call Ust via the list access "Read entries" command (see 
clause 7.4.10.4.3.1) feature. 

7.4.1 .4 List change notification 

See "List access service", Ust change notification procedure (see clause 7.4.10.2) for the detailed behaviour. 
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7.4.2 Date and Time synchronization 

Equipment supporting New Generation DECT wideband voice shall support the "Date and Time synchronization" 
feature as described in the present clause. 

The DECT entity shall use an already established link for the purpose of transmitting the {FACILITY} message 
containing the «TIME-DATE» information element to the peer entity. It is the responsibihty of the entity to ensure 
that time and date information within the peer entity is up to date. 

If there is no existing connection when sending the {FACILITY} message, the CLSS procedure may be used as defined 
in clause 10.4.2.3 of EN 300 175-5 [5] with the «TIME-DATE» information element in the {FACILITY} message. 

Whatever the {FACILITY} transport mode (CLSS procedure or re-use of aheady established link), the {FACILITY} 
message shall be used with dummy transaction identifier value 6 and the protocol discriminator CISS. 

For the values used in « TIME-DATE » information element see table 16. 



Table 16: Values used within {FACILITY} message for date and time synchronization 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Time-Date» 










<Coding> 


11B 


11 Time and Date 




<lnterpretation> 





The current time/date 




<Ti me/date > 


All 





Additionally, the entity which is sending the {FACILITY} message should set correctly the <Time Zone> field of the 
«T1ME-DATE» IE, (GMT, GMT+lh. . .). If this information is not available from the entity <Time Zone> field shall 
be set to null value. This may be the case for an FP when the information is not provided by the network. 

Upon reception of a {FACILITY} message with a content as defined in table 16, the peer entity shall set its time and 
date information to the received one. The date and time on FP side is called "DECT system date and time" in the 
following text. 

The FP and PP shall both support the "FT initiated Date and Time synchronization" procedure of clause 7.4.2.1, for 
synchronizing all PPs with the DECT system date and time. 

The PP should support and the FP shall support the "PT initiated Date and Time synchronization" procedure of 
clause 7.4.2.2. If used by the PP, the FP should not use clause 7.4.2.1 at the same time with the same PP especially 
when using the date and time from the network. 

The present procedure (see clause 7.4.2) shall be consistent with the "Clock master" setting (see clause 7.4.11.3.2) of 
the DECT system settings hst (see clause 7.4.11.3), "List access service", feature [NG1.N.16]. 

• If the "Clock master" field is equal to "FP", PPs shall not use the "PT initiated Date and Time synchronization" 
procedure. The FP may set the DECT system date and time as received from the network (e.g. received upon 
network incoming call, or through NTP), or from a dedicated interface (e.g. local or web interface). 

• If the "Clock master" field is equal to "PP": a PP shall be able to define the DECT system date and time on the 
FP, using procedure "PT initiated Date and Time synchronization" of clause 7.4.2.2. The FP shall ignore any 
date and time received by any other means (e.g. received from the network). 

In both cases, the FP shall use procedure "FT initiated Date and Time synchronization" of clause 7.4.2.1 to update the 
date and time of all (other) registered handsets. 

7.4.2.1 FT initiated Date and Time synclironization 

The present procedure shall be used by the FP in order to update the PP date and time and synchronize it with the DECT 
system date and time. The DECT system date and time could have been provided by the network, or by one of the PPs 
using procedure "PT initiated Date and Time synchronization" of clause 7.4.2.2. 
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NOTE: When the "Clock master" setting is implemented, the DECT system date and time origin is restricted. 
However a PP should never ignore the FP notification, even if the "Clock master" field is set to PP, 
because the DECT system date and time may have been set by another PP. 

If link is not available, the FP shall initiate indirect Unk establishment as defined in clause 7.3.8 of TS 102 527-1 [21] 
"Indirect FT initiated link establishment" procedure. The short format or the full format paging messages with 
corresponding slot types shall be used as for a regular incoming voice call. The LCE header shall be set to the "000" 
value (indicating "no U-plane" ) or to the "100" value (indicating "General code for voice service"). Full slot and long 
slot (j=640) are allowed as slot type. The chosen slot type (long or full) is decided by the initiating party (FT). 



PP FP 





FACILITY 


-4 


«TIME-DATE» 



Figure 1 : FT initiated Date and time synchronization 



7.4.2.2 PT initiated Date and Time synchronization 

In some cases (e.g. if the date and time are not provided by the network or erroneous), the DECT system date and time 
may be provided by one of the PPs, using the present procedure. 

When the "Clock master" field is equal to "PP", the DECT system date and time shall only be provided by one of the 
PPs using the present procedure. 

If link is not available, the PP shall initiate direct Unk establishment as defined in clause 8.36 of EN 300 444 [12] 
"Direct PT initiated link establishment" procedure. Full slot and long slot (j=640) are allowed as slot type. The chosen 
slot type (long or full) is decided by the initiating party (PT). 

The FP shall check the «Portable Identity» IE sent by the PP in the {FACILITY} message. If the date and time is 
sent by an unidentified PP, the FP shall ignore the time and date. The procedure "FT initiated Date and Time 
synchronization" of clause 7.4.2.1 may be used subsequently, in order to transfer the updated date and time to all other 
registered PPs. 



PP FP 

FACILITY 

«Portable ldentity» «TIME-DATE» 
Figure 2: PT initiated Date and time synchronization 



7.4.3 Handling of parallel calls 
7.4.3.1 Parallel call common requirements 

Procedures in clause 7.4.3 apply to DECT systems allowing to handle several simultaneous calls, and offer a common 
handUng of them in various situations (PSTN double calls, VoIP multiple calls on a single line, as well as parallel call 
situations occurring in a multiple line DECT system). Clause 7.4.3 also includes related procedures (for "Call transfer", 
"Call intrusion" and "3-party conference with established internal and/or external calls"). 

The "Parallel call" feature is a prerequisite feature including high level procedures and requirements. Clauses "Common 
parallel call procedures", "Call transfer", "Call intrusion" and "3-party conference with established internal and/or 
external calls", are all handled here because they imply implementation of the "Parallel call" feature, but are however 
handled as separate featiu'es. 
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In all parallel call scenarios there shall always be only one hnk between FP and PP, with one U-Plane and one call 
control instance. 

7.4.3.2 Control messages 

The following control codes shall be transmitted as keypad information in {CC-INFO} (or {CC-SETUP} if exphcitely 
noted) messages and shall trigger the corresponding actions in the FP according to table 17: 
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Table 17: Control messages for control of parallel calls 



Procedure 


Control message 


Direction 


PP Status 


FP Status 


Outgoing parallel call initiation (internal) 


17H -1- number 
17H-H'*' (see note 1) 


PP to FP 


M 


M 


Outgoing parallel call initiation (external) 


1 CI 5H -1- number (see note 2) 


PP to FP 


M 


M 


Call waiting indication (external or internal) 


Call status CS call setup + IE 
«SIGNAL = 'call waiting tone' 
= 07H» + IE «CLIP» (see 
notes 3 and 8) 


FP to PP 


M 


M 


Intrusion call request indication (only 
internal) 


Call status "CS conference 
connect + ib «bioNAL = 
iniercepi lone vjim = u^ri» 
(see note 8) 


FP to PP 


o 


CI 702 


Call toggle request (external or internal) 


■i O 1 u 
\ L/M ol n 


DP to CD 
rr 10 rr 


IVI 


IVI 


3-party conference call request (external or 
internal) 


1CH32H 


PP to FP 





C1703 


Call release (of the indicated call) 


1CH 33H 


PP to FP 


M 


M 


Call transfer request (external or internal) 


1CH 34H 


PP to FP 


M 


M 


Call waiting acceptation 


1CH 35H 


PP to FP 


M 


M 


Call waiting rejection 


1CH 36H 


PP to FP 


M 


M 


Active call release with replacement (from 
PP to FP) 


1CH 38H 


PP to FP 





M 


Negative acknowledgement 


Confirmed call status -i- IE 

«SIGNAL, 09H = negative 
acknowledgement tone» (see 
note 8) 


FP to PP 


M 


M 


Explicit call intrusion 


1CH 40H in {CC-SETUP} -1- 
targeted terminal identifier 

number (handset intrusion) or 
targeted line id (line intrusion) 


PP to FP 





CI 702 


Putting a call on-hold 


1CH 41H 


PP to FP 





M 


Resuming a call put on-hold (see note 9) 


1CH 42H 


PP to FP 


M 


M 


Call interception request from HPP (or PP) 
(see note 7) 


1CH 50H in {CC-SETUP} 


PP to FP 


CI 701 


M 


C1 701 : If the FT is a headset PP THEN "M" ELSE "0". 

CI 702: If FP implements intrusion call feature (NG1.N10) THEN "M" ELSE minimum requirement of "negative 
acknowledgement" with call status reason 'control code not supported' (see clause 7.4.3.4). 

C1 703: If FP implements conference call feature (NG1 .N9) THEN "M" ELSE minimum requirement of "negative 
acknowledgement" with call status reason 'control code not supported' (see clause 7.4.3.4). 


NOTE 1 : The '*' is used to call all the registered handsets (except the initiator) and the FP when capable of; this function 

is also called "internal general call" as defined in Generic Access Profile (GAP) 

EN 300 444 [12]. It may be also used when only two PPs are registered (this allow to omit the terminal 

number). 

NOTE 2: This value is purposely distinct from '15'H value, although it is used here in a similar context. Use of 31 H, 32H, 
33H, 35H, etc., as number after 1 5H may have a specific meaning for the network. For backward compatibility 
reasons, the FP may have to interpret these codes as control messages or send them transparently to the 
network. 

NOTE 3: Numbering plan id field of CLIP IE is set to "private numbering plan" for internal calls, any other type for 

external calls (as specified in TS 102 527-1 [21]). 
NOTE 4: The definition of the new CO-control code 1 C is proposed for use as described in table 1 7. 
NOTE 5: The new DECT codes may need a translation into network control messages on FP side. These messages 

are network operator dependent. 
NOTE 6: Network control messages may be sent directly by the user as keypad information. The FP should send them 

transparently to the network. 

NOTE 7: "Call interception" means that a PP intercepts a call initiated (i.e. being setup or in active state) by another PP. 

The intercepting PP is in principle a headset PP but could be any standard PP (see clause 7.4.16.2). This 

control code will be transmitted as keypad information in a {CC-SETUP} message. 
NOTE 8; See clause 7.4.6.4 for the definition of call statuses. Presence of «Signal» IE depends on the "Tones 

provision" feature. See clause 7.4.3.4 for more details on the negative acknowledgement. 
NOTE 9: "Resuming a call put on hold" (1C 42H) is mandatory for PPs since it may be needed by the call release 

procedure (see clause 7.4.3.5.4). The control code may be sent after interaction with the user, or automatically 

by the PP. 
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7.4.3.3 Codec change for parallel calls 

In case the parallel calls use different codecs, the standard codec change procedure shall be used (see 
TS 102 527-1 [21], clause 7.3.4 and annex D). 



PP FP 



Call established 



CC-INFO 



«MULTI-KEYPAD, 17H/15H» 

CC-INFO 
«MULTI-KEYPAD, number digits» 

CC-INFO 
«MULTI-KEYPAD, number digits» 

CC-SERVICE-CHANGE 

«CODEC-LIST» 
GG-SERVICE_ACCEPT 

IWU-INFO 
«CODEC-LIST» 

IWU-INFO 
«CODEC-LIST» 



Figure 3: Codec change procedure: example for outgoing call initiation 

7.4.3.4 Sending negative acknowledgement 

When the FP fails to fulfil a service requested by the PP, the FP shall reply to the PP with the current call status and 
with an appropriate call status reason (e.g. 'control code failed'), using procedure "Call status indication to the handset 
(FP to PP)" of clause 7.4.6.4. 

NOTE 1: The re-sending of the current call status is used to confirm that the service request was ineffective and did 
not result in a call status change. 

NOTE 2: The call status reason to be used is indicated when the present procedure is referred to in other 
procedures. 

The FP shall additionally send a 'negative acknowledgment tone' to the PP. The "Tones provision" feature describes the 
method that shall be used by the FP and PP to support the tone. 

A possible cause of failure may be unsuccessful interaction of the FP with the network. In that case the FP shall use the 
present procedure, using the call status reason 'control code failed'. 

NOTE 3: In the special case where the requested service cannot be fulfilled because it would exceed the DECT 

system or Une capacity, the "Busy system or Une notification" procedure of clause 7.4.8.3 is used instead. 
The main identified use case is in the context of multiple call lines (clause 7.4.8) but other parallel call 
use cases are relevant (e.g. in the context of a multiple lines DECT system). See also NG1.N.6 in 
clause 6.10. 
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As a special case, when the FP does not support a feature, but however receives from a PP a request for initiating that 
feature with the corresponding control code, the FP shall use the present procedure, using the call status reason 'control 
code not supported'. 

NOTE 4: As stated above, use of the present procedure includes re-sending of the current call status before the PP 
request was sent, together with the call status reason. 

EXAMPLE: The optional features 'intrusion call' (NGl .N. 10), 3PTY conference call (NGl .N.9), and call 
deflection (NGl.N.l 1) are examples of features that the FP may not support. 

7.4.3.5 Common parallel call procedures (external or internal) 

This clause details the procedures of a feature entitled "Common parallel call procedures (external or internal)". This 
feature is a set of common procedures for handling PSTN double calls, VoIP multiple calls on a single line, as well as 
parallel call situations occurring in a multiple line DECT system (and especially for PPs attached to multiple Unes in 
such a system). 

These procedures apply to the FP and a PP already involved in at least one call on a line in a DECT system. If the 
"Multiple call" feature is implemented on a line, this line may be configured in "single call" mode, or in "multiple call" 
mode (see clause 3.1). 

Implementation of the "Parallel calls" feature is a pre-requisite on PP and FP sides for implementation of the "Common 
parallel call procedures (external or internal)" feature. 

Implementation of the "Call Identification" feature on PP side and on FP side is a prerequisite for implementation of the 
"Common parallel call procedures (external or internal)" feature on a DECT system. 

Implementation of the "Line Identification" feature on PP side and on FP side is a prerequisite for implementation of the 
"Conmion parallel call procedures (external or internal)" feature on a DECT system. 

A PP implementing the "Connmon parallel call procedures (external or internal)" shall be able to support at least two 
simultaneous call contexts. 

Implementation of the "Common parallel call procedures" feature is itself a prerequisite for the implementation of the 
"Multiple calls" feature, or of the "Multiple Unes" feature on a DECT system. 

7.4.3.5.1 Outgoing parallel call initiation (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

External outgoing parallel call initiation. The initiation of an external outgoing parallel call shall be done by sending 
the control code ICH, followed by the register recall (15H) keypad information in a « MULTI-KEYPAD » IE in a 
{CC-INFO} message. In the same or other {CC-INFO} message(s), one or more further keypad information containing 
the decimal coded digits of the external number shall follow. 

Internal outgoing parallel call initiation. The initiation of an internal outgoing parallel call shall be done: 

either by sending the internal call ('17'H) keypad information in a « MULTI-KEYPAD » IE in a first 
{CC-INFO} message and the decimal coded digits of the internal number, in a « MULTI-KEYPAD » IE in a 
second {CC-INFO}message; or 

by sending the internal call ('17'H) keypad information together with the digits in a « MULTI-KEYPAD » IE in 
one single { CC-INFO }message. 

In case of internal parallel call, the number shall be the terminal id number of the targeted PP, or '*' in case of "internal 
general call". '*' may also be used when only two PPs are registered (this allows to omit the terminal number). The 
number of registered PPs is available from the internal names list. 

An outgoing parallel call initiation (external or internal) from the PP impUcitly requests that the active call be put on 
hold by the FP (especially if external). 
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NOTE 2: If the parallel call is internal, the FP does not need to actually put the first call on hold toward the remote 
party but could just simulate it (e.g. by playing an audio film in the FP toward the remote party). 

After the PP has sent a first {CC-INFO}message, and if the PP intends to use several {CC-INFO} messages in order to 
complete the outgoing parallel call initiation, the PP shall wait until it receives the call id assigned by the FP before 
sending subsequent messages, and shall include the received call id in these messages. 

If the line or the FP cannot support the additional call: 

• the FP shall use the "Busy system or line notification" procedure of clause 7.4.8.3 (instead of returning a "CS 
call hold"), that is: 

call status 'CS call disconnecting' sent along with the appropriate call status reason (e.g. 'line in use' or 

'system busy'); 

«CALL INFORMATION» IE sent with call status 'CS idle' in order to free the caU id. 
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PP 



FP 



Outgoing 
parallel call 
initiation 



For NG-DECT Part 3 PPs 
only: 




Ongoing call (external or internal), call id = 1 



CC-INFO 




« MULTI-KEYPAD, < Keypad info = '1C15'H / '17' H > » 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 



fThe FP assigns a call i dentifier: 

Ipor NG-DECT Part 3 PPs 
jonly: 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 
id type/subtype = 'Call status', value = 'CS call setup ack' > 




Tlie PP selects tlie line to use: 



CC-INFO 



« CALL-INFORMATION, 
Line selected for the call by a Part 3 < id type = 'Line identifier', 
PP using the CALL-INFO method subtype = 'external call', 

(external call only) _ value = 'u' > 

< id type/subtype = 'Call Identifier', value = 'assigned call id' > 

OR 



Line selected for the call by a GAP, 
Part 1 or possibly Part 3 PP using « MULTI-KEYPAD, 
the KEYPAD method < Keypad info = '23 3u'H > » 

(external call only) 



_FP line confirmation^ 

(por NG-DECT Part 3 PPs 
only: 



CC-INFO 



« CALL-INFORMATION 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'assigned call Id' > 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION 

< id type/subytpe = 'Call Identifier', 
value = 'assigned call Id' > 



Figure 4: Outgoing parallel call initiation request with line selection by the PP 

Line selection: For sending to the FP the Une identifier selected for the new external call, one of the following methods 

shall be used: 



for Part 3 PPs only, included in a « CALL INFORMATION » information element sent in a {CC-INFO} 
message; or 



• for GAP and Part 1 PPs, and possibly for Part 3 PPs also, included in a « MULTI-KEYPAD » IE sent in a 
{CC-INFO} message. This method shall only be used if the line identifier is in the interval 0..9. If this method 
is used, the line identifier information shall consist in the pound key ("#") character ('23'H) followed by the 
line identifier digit, IA5 -coded on a single octet. 
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FP line confirmation: For Part 3 PPs, the FP shall confirm the selected line in a {CC-INFO} message sent back to the 

PP, including the line type information for the selected line. 

NOTE 3: Instead of the sequence given above, the PP might also combine 'ICIS'H / '17'H, hne selection and called 
number in two or three messages. In these cases the FP will answer correspondingly in two or more 
messages. See clauses C.3 "Multiple calls diagrams" and C.4 "Parallel call complex or alternative 

diagrams", for more information. 

FP-managed line selection: If the PP uses "FP-managed line selection" (see clause 7.4.5.2.4) for an external call, one 
of the following methods shall be used: 

• for Part 3 PPs only, by using the special line id value 'None' (see clause 3.1). This value shall be sent instead of 
a regular line id, at any possible time and in any possible location for sending a regular line-id. The FP shall 
send back to the PP the hne identifier value including the line type information for the selected Une for the 
call; 

• for GAP or Part 1 PPs, by having their default behavior of sending no hne identifier, hence imphcitly using 
"FP-managed Une selection". In front of a GAP or Part 1 PP, a Part 3 FP shall wait for the first keypad 
information received from PP. If this keypad information is different from '23'H ('#' character), the FP shall 
infer that "FP managed line selection" is used, and shall therefore select a line on behalf of the PP. The FP may 
notify back the user of the PP of the used line identifier using a «DISPLAY» information element, but shall 
not use any «CALL-INFORMATION» element toward the PP. 

See figure 5 for detailed sequence flowchart (part 3 PP case). 

Internal call: In case of internal call, no Une identifier shall be sent. 



PP ^ FP 





<C!]^^^ Ongoing call (external or internal), call id = 1 ^J]^^^ll> 


Outgoing call initiation 

Outgoing 
parallel call 
initiation 


CC-INFO ^ 


« IVIULTI-KEYPAD, < Keypad info = '1 01 5'H / '1 7'H > 




^ CC-INFO 


« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 


Call id assignment by the FP 


CC-INFO 


M 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 



FP-managed line selection: The 

Part 3 PP does not select the line 
to use (uses 'None' subtype). 



rFP sends tine line id: 
also if the PP is attached to 
only one line 

or if there is only one line in 
the system 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION 

< id type = 'Line identifier', subtype - 'external call', value = 'None'> 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 



CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type='Line identifier', subtype='line type information', value = 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

< id type/subtype = 'Call status', value = 'CS call proc' > 



'xy'B> 



Figure 5: Outgoing parallel call initiation request with FP-managed line selection 
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The call statuses shall comply with clause 7.4.6.4 provisions. 

The FP may change the audio codec for the parallel call by use of the service change procedure (see clause 7.4.3.3, 
"Codec change for parallel calls"). 

In case the parallel call is internal, the FP shall use the GAP "internal call CLIP" and "internal call CNIP" procedures 
for this parallel call (see clause 6.10). 

NOTE 4: In case of internal call, the '*' character can be used as called number, meaning that an 'internal general 
call' is attempted. 

7.4.3.5.2 Call waiting indication (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented and used 
on a line, the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature imphes implementation of 
the "Common parallel call procedures (external or internal)" feature. 

NOTE 2: In "single call" mode, PPs not involved in a call do not receive the call waiting indication and do not ring. 
In "multiple call" mode, there may be several PPs already involved in a call and all of them receive the 
call waiting indication; idle PPs receive an incoming call request and ring. 

Call waiting shall be indicated by the FP by sending in a {CC-INFO} message the information element 
«CALL-lNFORMATION» with the call status 'CS call setup'. Together with this procedure, the FP shall use the 
"CLIP on call waiting" procedure of clause 7.4.3.5.10. 

Whenever required by the "Tones provision" feature, the FP shall additionally send the «SIGNAL» IE with the value 
'07'H indicating 'call waiting tone on'. 

Whether sent in the same or in different {CC-INFO} messages, the sending of the three involved lEs shall respect the 
following rules: 

• call status in «Call lnformation» IE shall always be sent in the first used {CC-INFO} message. If the call is 
external, the line identifier (including the 'line type information') shall also be sent in the first used 
{CC-INFO} message, together with the call status; 

• whether sent in the same or different {CC-INFO} messages (including the first one above), the other two 
involved lEs shall always be sent in the following order: «Signal» (if any), «Calling Party Number». 

NOTE 3: These rules are consistent with the order specified in EN 300 175-5 [5], clause 6.3.2.2 for lEs within the 
same {CC-INFO} message. 

Furthermore, as a result of the "Call identification" feature, the FP shall assign an identifier for the waiting call, and 
send it in a «CALL-INFORMATION» information element included in every {CC-INFO} message used (one or 
two). 

If an internal call is waiting, the information element «Calling Party Number» shall indicate a private numbering 
plan. 
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PP FP 





Ongoing call (external or internal), call id = 1 

Call waiting Indication 

CC-INFO 




If required by the Tones « SIGNAL value = 'call waiting tone' = '07'H » 
provision' feature 


1 « CALL-INFORMATION, 


[||g.pn which waiting call < id type = 'Line identifier', subtype = 'external call', value = 'waiting call line id' > 
^HIHHHVHHMHbte) < id type = 'Line identifier', subtype = 'line type information', value = 'xy'B> 


CW tone 
heard by user 


< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

^ CC-INFO 


« CALLING PARTY NUMBER, < Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 



NOTE: The line identifier indicates to the PP on which line the waiting call occurred and also indicates the 'line 
type information' of this line (if external). 

Figure 6: Call waiting indication 

To accept the waiting call, the "Call waiting acceptation" procedure or the "Call waiting acceptation with active call 
released" procedure shall be used (see clauses 7.4.3.5.6 or 7.4.3.5.12). 

To reject the waiting call, the "Call waiting rejection" procedure shall be used (see clause 7.4.3.5.7). 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a "CS idle" call 
status to the PP, with the call id of the waiting call. 

7.4.3.5.3 Call toggle (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature impUes implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In case two parallel calls are established, in order to toggle between the calls, the PP shall send a toggle request to the 
FP consisting in the control code ICH as keypad information in a {CC-INFO} message, followed by 31H. Furthermore, 
the PP shall send the identifier of the call targeted by the togggle in a «CALL-INFORMATION» information 
element included in the same {CC-INFO} message. 

NOTE 2: A PP sends the call identifier of the targeted call, even if it toggles between two calls only. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

The FP shall indicate the result of the toggling by use of call status indications: 

if the toggle request is successful, the FP shall indicate first call status 'CS call hold' for the previously active 
call, and then 'CS call connect' for the targeted call; 

if the toggle request is unsuccessful, the FP shall send a negative acknowledgment as described in 

clause 7.4.3.4 (call status of the active call 'CS call connect' re-sent along with call status reason 'control code 

failed'). 
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Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call connect' 
Call ld=2, call status = 'CS call hold' 



Call toggle request 

CC-INFO 




« MULTI-KEYPAD, info = '1C 31'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'targeted call id' = '02'H> 



CC-INFO 

< 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 

M 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect'> 

» 

Figure 7: Call toggle request 



7.4.3.5.4 Call release and call release rejection 

This procedure applies to the FP and a PP already involved in at least two calls on a DECT system implementing the 
feature entitled "Common parallel call procedures (external or internal)", and is used by the releasing party in order to 

release one of these calls. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature imphes implementation of 
the "Common parallel call procedures (external or internal)" feature. 

NOTE 2: The call may still exist in the system, if one or several other PPs are still involved in the call. See for 
example use case C.3.2. For the relationship between call release and the call id Ufecycle, see also 
clause 7.4.6.1, "Call identification general requirements" 

When releasing the last parallel call of the PP, the PP shall not use the current procedure. However it is allowed for the 
FP to use it (e.g. send a 'CS idle' before it sends a {CC-RELEASE} to the PP). 

If the PP is the releasing party: 

• It shall send a 'call release request' to the FP, consisting in control code ICH as keypad information in a 
{CC-INFO} message, followed by 33H. Additionally, it shall send the identifier of the call to be released in a 
«CALL-E^}FORMATION» IE included in the same {CC-INFO} message. 

• If the FP can release the call, it shall answer with the call status 'CS idle' and the call identifier of the released 
call. 

• If the released call is the active call, the FP shall NOT automatically switch the speech path to one of the 
remaining parallel calls. The PP shall use the "Resuming a call put on-hold" procedure of clause 7.4.3.5.9 in 
order to indicate to the FP the on-hold call to be resumed. In order to use this procedure, the PP shall first: 

either interact with the user to let him choose the on-hold call to be resumed; or 

automatically select the on-hold call to be resumed. 
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NOTE 3: The only difference between the two options from protocol point of view is the delay between the 'CS 
idle' message from the FP, and the following resuming request from the PP. When the second option is 
used, the PP answer is immediate. 

NOTE 4: A call release request can be sent as soon as a call identifier has been sent by the FP to the PP (e.g. in case 
of a waiting call release, even before the waiting call has been answered). See also clause C.4.1.5. 

In some cases, when a call release request is sent by the PP, the FP might not be able to fulfil it, for instance when the 
call to be released is external. In that case: 

the FP shall send a negative acknowledgment as described in clause 7.4.3.4 (call status of the active call 'CS 
call connect' re-sent along with call status reason 'control code failed'); 

the FP shall send a negative acknowledgment as described in clause 7.4.3.4: call status of the call that was to 
be released (e.g. 'CS call connect' if it was the active call, 'CS call hold' if it was a call on-hold) re-sent along 
with call status reason 'control code failed'. 

If the FP is the releasing party, (i.e. as a result of a remote party hangup): 

It shall send the call status 'CS idle' together with the call identifier of the released call. This shall not be used 
with a newly defined call id (i.e. not yet communicated to the PP). 

If the released call is the active call, the FP shall NOT switch the speech path automatically. Instead, the user 
should additionally be warned (e.g. through a PP originating display) of the change in order to invite hinn/her to 
resume one of the on-hold remaining parties. The speech path can be then switched to one of the remaining 
parties using the procedure "Resuming a call put on-hold" of clause 7.4.3.5.9. 

NOTE 5: When the speech path is switched to one remaining party, the PP should update the displayed call 
information to show the active telephone number. 

NOTE 6: When the PP or FP releases the last parallel call, they do not use the current procedure. However, when 
the FP releases the last parallel call, it should still sent a 'CS idle' call status to the PP before the 
{CC-RELEASE} message is used. A {CC-RELEASE} message does not convey any call identifier. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

NOTE 7: To release all parallel calls, the PP may also send a single {CC-RELEASE} to the FP. 
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PP 



FP 



If the PP is the 
releasing party 



Although the released 
call is the active call, 
the FP shall not switch 
the speech path 
automatically to the 
existing on-hold call 




Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call connect' 
Call id=2, call status = 'CS call hold' 



(Successful) Call release request 

CC-INFO 




« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'id of call to be released' ='01 'H > 



» 



Call release request 
succeeds 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 



Optional user 
interaction for 
choosing the call to be 
resumed 



On-hold call (with call id 2) 
remains on-hold here 



Resuming a call put on-hold (7.4.3.5.9) 

CC-INFO 



« MULTI-KEYPAD, info = '1C 42'H » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'targeted call id' = '02'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 

» 



Figure 8: Successful call release of the active call (requested by the PP or not) 
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PP 



FP 



If required by the Tones 




Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call connect' 
Call id=2, call status = 'CS call hold' 



Call release request 

CO-INFO 




« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'id of call to be released' ='01 'H > 



Negative acknowledgement 

CC-INFO 



Call cannot be 
released 



« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 'id of call to be released' ='01 'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 

< id type = 'Call status', subtype = 'Call status reason', 

value = 'control code failed' > 



Figure 9: Failing call release request from the PP 

Release of a 3-party conference call. 

Additional requirements applying specifically to 3-party conference calls are described in clause 7.4.3.7 (release sub 
sections). 



7.4.3.5.5 



Void 



7.4.3.5.6 



Call waiting acceptation (from PP to FP) 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple caU" feature is implemented on a Une, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature imphes implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In case the PP is already involved in a call (active call) and after a call waiting has been indicated, the acceptation of the 
waiting call shall be done by sending the control code ICH as keypad information in a {CC-INFO} message, followed 
by 35H. Furthermore, the PP shall send the call identifier of the accepted waiting call in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: The PP sends the call identifier of the waiting call, even if there is a single call waiting. 

The active call shall be automatically put on hold and the waiting call shall become active. 
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The FP shall indicate as a result of the call waiting acceptation : call status 'CS call connect' for the waiting call, and 'CS 
call hold' for the previously active call. 

NOTE 3 : If any of these calls is released in the meantime by the remote party, the FP may directly send a "CS idle" 
(or "CS call disconnecting") on the corresponding call id instead. 

In "multiple call" mode, when the PP accepts the waiting call, ongoing procedures for handling the call on other PPs 
(using the present clause, or EN 300 444 (GAP) [12], clause 8.12, "Incoming call request", if it is a first call for the 
concerned PP) shall be terminated. In particular, idle PPs shall stop ringing. If several handsets either pick-up or accept 
the waiting call, only the first action shall be taken into account. The other actions shall be ignored. 

The FP may change the audio codec for the accepted call by use of the service change procedure. 



PP 



If required by the 'Tones 
provision' feature 



Line on which waiting call 
occurred if external 
(see notes 4 and 5) 



CW tone 
heard by user 




Ongoing call (external or internal), call id = 1 



CC-INFO 




Internal or external 
< call waiting from 
^ 'calling number' 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype='line type information', 

value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

Call waiting acceptation 

CC-INFO 



« MULTI-KEYPAD, info = '1C 35'H 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 'waiting call id' 

» 

CC-INFO 



In multiple call mode, 
other handsets stop 
ringing or receiving the 
CW indication 

'02'H> 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 



Figure 10: Call waiting acceptation 



NOTE 4: The line identifier indicates to the PP on which line the waiting call occurred and also the 'line type 
information' of this line (if external). 

NOTE 5: Although the 'network delay type' (within the 'line type information') is already sent in the first 

{CC_INFO} message from FP to PP, the PP may wait until the final {CC_INFO} caiTying the 'CS call 
connect' call status before actually adapting the acoustics parameters to the announced 'network delay 
type'. 



If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a 'CS idle' call 
status to the PP, as defined in clause 7.4.3.5.4, "Call release and call release rejection". 
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7.4.3.5.7 Call waiting rejection (from PP to FP) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a Une, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1 : Implementation of the "Multiple call" featiu"e or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In case the PP is already involved in a call (active call) and after a call waiting has been indicated, the rejection of the 
waiting call shall be done by sending the control code ICH as keypad information in a {CCTNFO} message, followed 
by 36H. Furthermore, the PP shall send the call identifier of the rejected waiting call in a «CALL-INFORMATION» 
information element included in the same {CC-INFO} message. 

NOTE 2: The PP sends the call identifier of the waiting call, even if there is a single call waiting. 

The FP shall indicate the result of the call waiting rejection by use of call status indications: 

if the call waiting rejection is successful, the FP shall indicate call status 'CS idle' for the waiting call; 

if the call waiting rejection is imsuccessful, the FP shall send a negative acknowledgment as described in 
clause 7.4.3.4 (call status of the waiting call 'CS call setup' re-sent, along with call status reason 'control code 
failed'). 

NOTE 3: This cannot be used to avoid implementation of the procedure. In other words, there is no 
'unimplemented' call status reason. 



PP 




Ongoing call (external or internal), call id = 1 




Line on which waiting call 
occurred if external 
(see notes 4 and 5) 



CW tone 
heard by user 



for this PP only: 



Internal or external 
call waiting from 
'calling number' 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype='line type information', 

value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

Call waiting rejection , ... , ,, . 

" ' In multiple call mode, 

CC-INFO _ other handsets continue 



« MULTI-KEYPAD, info = '1C 36'H 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H> 

CC-INFO 



ringing or receiving the 
CW indication 



« SIGNAL, value = 'Tones off = '3F'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value= 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 

Figure 11: Call waiting rejection 

NOTE 4: The line identifier indicates to the PP on which line the waiting call occurred and also the 'line type 
information' of this line (if external). 
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NOTE 5: On a multiple call line configured in "multiple call" mode, "call waiting rejection" does not necessarily 
imply that the call is rejected by the DECT system. 

In "multiple call" mode, when the PP rejects the waiting call, the "Call waiting indication procedure" shall be 
terminated for this PP, but this shall not affect the handling of this call on other handsets: ongoing procedures for 
handling the call on other PPs (using the present clause or EN 300 444 [12] (GAP), clause 8.12, "Incoming call request" 
if it is a first call for the concerned PP) shall not stop. In particular, idle PPs shall not stop ringing. 

NOTE 6: To reject the call for the whole DECT system, a call release may be used instead of the present procedure, 
using the "Call release and call release rejection" of clause 7.4.3.5.4 for the waiting call. 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a 'CS idle' call 
status to the PP, as defined in clause 7.4.3.5.4, "Call release and call release rejection". 

7.4.3.5.8 Putting a call on-hold 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1 : Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In order to put a call on-hold, the PP shall send the control code ICH as keypad information in a {CC-INFO} message, 
followed by 41H. Furthermore, the PP shall send the identifier of the call to be put on-hold in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: The PP sends the call identifier of the call to be put on hold, although it is always the active call. 

The FP shall indicate the result of the "Putting a call on-hold" procedure by use of a call status indication: 

if the procedure is successful, the FP shall indicate call status 'CS call hold' for the targeted call; 

if the procedure is unsuccessful, the FP shall send a negative acknowledgment as described in clause 7.4.3.4 
(call status of the targeted call 'CS call connect' re-sent, along with call status reason 'control code failed'). 

NOTE 3: This cannot be used to avoid implementation of the procedure. In other words, there is no 
'unimplemented' call status reason. 




Request for putting a call on-hold 

CC-INFO ^ 

« MULTI-KEYPAD, info = '1C 41'H » 
« GALL-INFORMATION, 

< id type/subtype = 'Gall identifier', value ='targeted call id' = '01 'H > 



^ GG-INFO 

« GALL-INFORMATION, 

< id type/subtype = 'Gall identifier', value ='targeted call id' = '01 'H > 

< id type/subtype = 'Gall status', value = 'GS call hold' > 

» 

Figure 12: Putting a call on liold 

NOTE 4: In the specific case where the call put on-hold is a conference call, the conference (audio path) should 
remain active in the FP for the two other participants. 
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NOTE 5: The use case when the user wants to put only one of the participant's call of a conference on hold is not 
described in the present document. 

7.4.3.5.9 Resuming a call put on-hold 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature impUes implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In order to resume a call that was put on-hold, the PP shall send the control code ICH as keypad information in a 
{CC-INFO} message, followed by 42H. Furthermore, the PP shall send the identifier of the call to be resumed in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 

The procedure shall not be used in case of existing active call. 

NOTE 2: The PP sends the call identifier of the call to be resumed, even if there is only one call on-hold. 

The FP shall indicate the result of the "Resuming a call put on-hold" procedure by use of a call status indication: 

• if the procedure is successful, the FP shall indicate call status 'CS call connect' for the targeted call; 

• if the procedure is unsuccessful, the FP shall send a negative acknowledgment as described in 7.4.3.4 (call 
status of the targeted call 'CS call hold' re-sent, along with call status reason 'control code failed'). 




Request for resuming a call put on-hold 

CC-INFO ^ 

« MULTI-KEYPAD, info = '1 C 42'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value ='targeted call id' = '01 'H > 

■>■> 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value ='targeted call id' = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 



Figure 13: Resuming a call put on hold 



7.4.3.5.1 CLIP on call waiting 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a Une, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

CLIP on call waiting shall be indicated by the FP to the PP. 

This indication shall be done by sending in one of the { CC-INFO } message used, the «Calling Party Number» IE. 
More specifically, whether sent in the same or in different {CC-INFO} messages, the sending of the three involved lEs 
shall respect the following rules: 

call status in «Call Information» IE shall always be sent in the first used {CC-INFO} message. If the call is 
external, the line identifier (including the 'line type information') shall also be sent in the first used {CC-INFO} 
message, together with the call status. 
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whether sent in the same or different {CC-INFO} messages (including the first one above), the other two 
involved IBs shall always be sent in the following order: «Signal» (if required by the "Tones provision" 
feature),, «Calling Party Number». 

NOTE: These rules are consistent with the order specified in EN 300 175-5 [5], clause 6.3.2.2 for lEs within the 
same {CC-INFO} message. 

If the waiting call is an internal call, the information element «Calling Party Number» shall indicate a private 
numbering plan. 



PP 



FP 




Ongoing call (external or internal), call id = 1 



CC-INFO 




Line on which waiting call 
occurred if external 



CW tone 
heard by user 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype = 'line type information', 
value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

9P- I.^ 'l9 required by the 'Tones 

provision' feature 
« SIGNAL value = 'call waiting tone' = '07'H » ^ 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 

CLIP on call waiting 

CC-INFO 



« CALLING PARTY NUMBER » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 



Figure 14: CLIP on call waiting 



7.4.3.5.1 1 CNIP on call waiting indication 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a Une, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

CNIP on call waiting shall be indicated by the FP to the PP. 

This indication shall be done by sending, in one of the {CC-INFO {messages used, the «Calling Party Name» IE. 
More specifically, whether sent in the same or in different {CC-INFO} messages, the sending of the four involved lEs 
shall respect the following rules: 

• Call status in «Call Information» IE shall always be sent in the first used {CC-INFO} message. If the call is 
external, the line identifier (including the 'line type information') shall also be sent in the first used 
{CC-INFO} message, together with the call status. 

• Whether sent in the same or different {CC-INFO} messages (including the first one above), the other three 
involved lEs shall always be sent in the following order: «Signal» (if required by the "Tones provision" 
feature), «CalUng Party Number», «Calling Party Name». 

NOTE 1: These rules are consistent with the order specified in EN 300 175-5 [5], clause 6.3.2.2 for lEs within the 
same {CC-INFO} message. 
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PP 



FP 




Ongoing call (external or internal), call id = 1 



CC-INFO 




Line on which waiting call 
occurred if external 



CW tone 
heard by user 



« CALL-INFORMATION, 

< id type = 'Line Identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype = 'line type information', 

value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

^ 9?."l.^'l9 'f required by the 'Tones 

orovision' feature 
« SIGNAL value = 'call waiting tone' = '07'H » ^ 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 



« CALLING PARTY NUMBER » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 

CNIP on call waiting 

CC-INFO 



« CALLING PARTY NAME » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 



Figure 15: CNIP on call waiting 



NOTE 2: In case both CLIP and CNIP are sent to the PP, it is sufficient to display one of them. It is optional to 
display both. 



7.4.3.5.12 Active call release with replacement (from PP to FP) 

The present procedure is primarily intended for backward compatibility of NG-DECT systems with PSTN lines using 
the 'R' key as unique control code. The release of the active call, and the replacement thereof with another call in the 
following two cases: 

1) there is a waiting call, and following the 'active call release request with replacement', the current active call is 
released and replaced with the waiting call; 

In case 1, all requirements of procedure "Call waiting acceptation (from PP to FP)" of clause 7.4.3.5.6 
shall apply, with following modifications: 

■ control code ICH as keypad information in a {CC-INFO} message, followed by 38H (instead of 
35H) shall be used; 

■ when accepting the waiting call, the active call is released instead of being put on hold. 

2) there is a call on hold, and following the 'active call release request with replacement, the current active call is 
released and replaced with the call on hold; 

In case 2, all requirements of procedure "Call toggle (external or internal)" of clause 7.4.3.5.3 shall 
apply, with following modifications: 

■ control code ICH as keypad information in a {CC-INFO} message, followed by 38H (instead of 
31H) shall be used; 
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■ the active call is released instead of being put on hold. 
In both cases, the active call that will be released may be an internal or external call. 

In both cases the used call id is the call id of the call that becomes active after the request is fulfilled. In case there is 
both a call waiting and a call on hold, the used call id allows to disambiguate the request. 



PP 



If required by the 'Tones 
provision' feature 



Line on which waiting call 
occurred if external 




Ongoing call (external or internal), call id = 1 



CC-INFO 



« SIGNAL value = 'call waitinq tone' = '07'H » 

« CALLING PARTY NUMBER, 

< Galling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype='line type information'. 




Internal or external 
call waiting from 
calling number' 



CW tone 
heard by user 



< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 



Active call replacement request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 38'H 
« CALL-INFORMATION, 

< id type = 'Call identifier', value = 'waiting call id' = '02'H> 

CC-INFO 



In multiple call mode, 
other handsets stop 
ringing or receiving the 
CW indication 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H> 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 



< id type/subtype = 'Call status', value = 'CS call connect' > 



» 



Figure 16: Active call replacement with the waiting call 



7.4.3.6 Call transfer 

Call transfer is used by the user of a PP involved in two parallel calls to connect the remote parties together before 
ending the existing calls. If one of the remote parties is a handset registered to the same FP, the transfer can be handled 
at FP level; otherwise, the success of the transfer is network-dependent. 

Transfer target: The phrase "transfer target" refers to the internal or external party to which the call is transferred. 

Implementation of the "Common parallel calls procedures" feature is a pre-requisite on PP and FP sides for 
implementation of the "Call transfer" feature. 

The call transfer may be announced or unannoimced, depending on when the call transfer control message is sent by the 
PP. 
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In order to transfer a call, the PP shall first establish a parallel call with the call transfer target, and then send the control 
code ICH as keypad information in a {CC-INFO} message, followed by 34H. Furthermore, the PP shall send the 
identifier of the call to be transferred in a «CALL-INFORMATION» information element included in the same 
{CC-INFO} message. 

The FP shall understand a call transfer request as a request for transferring the previously active call to the currently 
active call. 

The call release, using a {CC-RELEASE} message shall be issued by FP. When the transfer target is internal and only 
after the {CC-RELEASE} message has been sent (i.e. when the call transfer can be considered effective on FP side), 
the FP shall issue a call identifier update for the PP target of the call transfer, as shown in figures 17 and 18, indicating 
the call identifier of the transferred call as updated call identifier. 

Call transfer abort: 

The PP may release the internal call before the call transfer is requested, this is handled as a regular parallel call release 
(see clause 7.4.3.5.4). (No later call transfer is then possible). 

The PP may abort a call transfer after the call transfer request has been actually sent to the FP. To achieve the user 
abort, the PP shall send a call release to the FP, using "Call release and call release rejection" of clause 7.4.3.5.4 to 
release the parallel call initiated for the transfer. The speech path shall be then automatically switched to the waiting 
peer. 

NOTE 1: Implementation of call transfer abort on PP side is not strictly necessary except for the announced call 
transfer case (see clause 7.4.3.6, "No answer from transfer target" section). 

MMI independence: 

The requirements and flowcharts of the call transfer procedures described below allow various user experiences. For 
exiimple the following MMI implementations are compatible: 

Implementation 1: A dedicated call transfer button/menu/action is offered each time the user establishes a second call 
(a 'call transfer request' is sent to the FP as soon as the user selects this option). Then the user 
separately hangs up, which triggers the sending of a {CC-RELEASE} to the FP. 

Implementation 2: Establishing a second internal call and hanging up is considered as an implicit call transfer request 
from the user. After user hangup, the PP sends in a row a 'call transfer request' and a 
{CC-RELEASE} to the FP. 

NOTE 2: In implementations 1 and 2, a user hangup can never be considered as a user request for call transfer 
abort. In particular, offering call transfer abort to the user with implementation 2 would require a 
dedicated MMI item (e.g. re-press the INT key). 

Implementation 3: same implementation as implementation 1 except that the FP sends a {CC-RELEASE} message 
after reception of the call transfer request from the PP. 

CLIP and CNIP. Procedures "Remote party CLIP on call transfer" (see clause 7.4.3.6.4) and "Remote party CNIP on 
call transfer" (see clause 7.4.3.6.5) shall be used. 

7.4.3.6.1 Announced call transfer procedure 

For the "Announced call transfer" procedure, all requirements of clause 7.4.3.6 apply. Additionally, if the control code 
is sent after establishing the connection with the transfer target, allowing for a transient call with the transfer target, the 
transfer is defined as announced. 

Announced call transfer "failure" cases: 

No answer from transfer target: when the transfer target does not answer, the FP should stop the call presentation 
upon timer expiry, and then provide the initiating PP with an off-hook warning tone according to "Tones provision" 
NG1.N.20 procedures. The initiating PP shall then abort the call transfer as described in call transfer abort section of 
clause 7.4.3.6. 

NOTE 1 : In other words, the present "Announced call transfer" procedure requires implementation of a call 

transfer abort in order to be able to resume the call with the initial remote party (piffallel call release 
before the call transfer is requested). 



ETSI 



75 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



NOTE 2: Despite the announced call transfer means that the transfer target answers the call, this sub procedure 
cannot be considered as out of scope of the announced call transfer procedure as it corresponds to a 
possible failure case. 

Waiting peer premature hangup: Premature hangup occurs if the waiting peer hangs up after the FP has received the 

call transfer request but before the waiting peer and transfer target were connected. In that case the FP shall ignore the 
call transfer request. The initiating PP may either continue with the second call (especially if it received the waiting peer 
release information), or release it. 

NOTE 3: If the waiting peer hangs up before the FP has received the call transfer request, the FP cannot assume 
that a call transfer was going to happen and is still in a regular double call scenario. The FP should 
therefore keep the second call going (whether still presented or already connected). If a subsequent call 
transfer request is however received, it is also ignored as it refers to an idle call id. 

NOTE 4: When the initiating PP receives the release information resulting from the waiting peer hangup, it should 
not send the call transfer request even if already requested by the user. 
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PP1 



FP 



call established 
(external or internal) witli call id 1 



Try to establish parallel internal call 2 

CC-INFO 




PP2 



« MULTI-KEYPAD, 17H + terminal id number » 
CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call proc > 



CC-INFO Ring-back tone 

'' «sIgNAL value = '01' H » If required by the 'Tones provisi|Dn' feature 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status', value = 'CS call alerting > 

» 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS call connect' > » 




CC-SETUP 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status' value ='CS call setup' > 



CC-ALERTING 



CC-CONNECT 



Call 
pick-up 



CC-CONNECT-ACK 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS call connect' > >: 



call 2 established for announcing call transfer 



Call transfer request 



CC-INFO 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier' value = '1'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '1' > 

< id type/subtype = 'Call status', val = 'CS idle' > 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS idle' > 

CC-RELEASE 



CC-RELEASE-COM 



Line of the transferred call 
If external (see note 9) 




CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line id' subtype = 'external call' 

value = 'transferred call line id' = 'u' > 

< id type='Line id enyfie r', subtype='line typ e irifcrmation', 

value 'xy'VfeHlHlBi^HHHMHHH 

< id type/subtype =^airiaentmervSue^ 

< id type = 'Call id' subtype = 'Updated call id' val = '1'H : 

< id type/subtype = 'Call status', val = 'CS call connect' > 
» 



Figure 17: Announced call transfer (example with internal target PP2): 
"call transfer request" after {CC-CONNECT} 
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NOTE 5: The Call Control message sequence in figure 17 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 6: PP2 may be idle or busy (involved in another call). If busy, PP2 would receive a parallel internal 
incoming call instead of a first internal incoming call. 

NOTE 7: A multiple call line may not support the additional internal call. In that case, PPl will receive back a busy 
line notification, which will terminate the procedure. 

NOTE 8: In figure 17, the second call is established using the "Outgoing parallel call initiation" procedure of 
clause 7.4.3.5.1; however, any procedure leading to two parallel calls may precede the call transfer 
procedure. 

NOTE 9: The call id update at the end of figure 17 contains the Une id value and the 'line type information' of the 
transferred call, in order to inform PP2 of the line (and Une type) used for this call. 



7.4.3.6.2 Unannounced call transfer procedure 

For the "Unannounced call transfer" procedure, all requirements of clause 7.4.3.6 apply. Additionally, if the control 
code is sent without knowing whether the transfer target would actually answer, the transfer is defined as unannounced. 

Unannounced call transfer "failure" cases: 

No answer from transfer target: When the transfer target does not answer, the FP should stop the call presentation 
upon timer expiry. The FP should then call back the initiating PP to re-connect the waiting peer party. 

Waiting peer premature hangup: Premature hangup occurs if the waiting peer hangs up after the FP has received the 

call transfer request but before the transfer target answered. If not already done at the time the waiting peer hangs up, 
the FP shall release the second call toward the initiating PP in response to the received 'call transfer request', as for a 
successful call transfer. The FP shall then stop the presentation of the second call to the transfer target. 

NOTE 1: If the waiting peer hangs up before the FP has received the call transfer request, the FP cannot assume 
that a call transfer was going to happen and is still in a regular double call scenario. The FP therefore 
keeps the second call going. If a subsequent call transfer request is however received, it is ignored as it 
refers to an idle call id. 

NOTE 2: If the initiating PP receives the release information resulting from the waiting peer hangup, it should not 
send the call transfer request even if already requested by the user. 
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PP1 



call established 
(external or internal) witli call id 1 



Try to establish parallel internal call 2 

CC-INFO 




FP 



PP2 



« MULTI-KEYPAD, 17H + terminal id number » 
CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call proc > 



CC-INFO 



Ring-bacl< tone 



« SIGNAL value = '01 'H » 



If required by the 'Tor es provision' feature 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status', value = 'CS call alerting > 

» 



Call transfer request 



CC-INFO 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier' value = '1'H > 

» 

CC-INFO 



« CALL-INFO, < id type/subtype = 'Call identifier', value = '1' > 

< id type/subtype = 'Call status', val = 'CS idle' > 

CC-INFO 

CALL-INFO, < id type/subtype = 'Call identifier', value = '2' 

< id type/subtype = 'Call status', val = 'CS idle' > 



CC-RELEASE 



CC-RELEASE-COM 



Line of the transferred call 
if external (see note 6) 



CC-SETUP 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status' value ='CS call setup' > 



CC-ALERTING 



CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line id' subtype = 'external call' 

value = 'transferred call line id' = 'u' > 

< id type='Line identifier', subtype='line type information', 
itMflM^^value = 'xy'B >.^.^>^^imt^mmmmmammmmmm 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type = 'Call id' subtype = 'Updated call id' val = '1'H > 

< id type/subt = 'Call status' val ='CS call under transfer' > 

CC-CONNECT Call pick-up 



CC-CONNECT-ACK 



CC-INFO 

« CALL-INFO,"" "* 

< id type/subtype = 'Call id', value = '1 ' > 

< id type/subtype = 'Call status', val = 'CS call connect' > 



Figure 18: Unannounced call transfer (example with internal target PP2): 
"call transfer request" before {CC-CONNECT} 
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NOTE 3: The Call Control message sequence in figure 18 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 4: PP2 may be idle or busy (involved in another call). If busy, PP2 would receive a parallel internal 
incoming call instead of a first internal incoming call. 

NOTE 5: A multiple call line may not support the additional internal call. In that case, PPl will receive back a busy 
line notification, which will terminate the procedure. 

NOTE 6: The call id update at the end of figure 18 contains the line id value and the 'line type information' of the 
transferred call, in order to inform PP2 of the line (and line type) used for this call. 

7.4.3.6.3 Call re-injection to the system (external or internal) 

The purpose of the "Call re-injection to the system (external or internal)" procedure is to transfer a call (external or 
internal) -announced or vmannoimced- to all PPs. Both methods (announced and unannounced) shall be supported. 

All requirements of clause 7.4.3.6 apply; the only difference being that the initiator requests an internal general call 
instead of an internal call to a targeted PP. 

NOTE 1: Internal general caU is defined in Generic Access Profile (GAP) EN 300 444 [12]. 

When the transferred call is internal (i.e. waiting peer entity is another PP), the FP shall not present the call to this PP. 

Call re-mjection"failure" cases : 

Depending on whether the call re-injection is announced or unannounced, the provisions of clause 7.4.3.6.1 or 7.4.3.6.2 
in case of call transfer failure respectively apply with the following rules : 

• Provisions applying to the transfer target before picking up apply here to all PPs except the initiating PP. 

• Provisions applying to the transfer target after picking up apply here to the answering PP only. 
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PP1 



FP 





Call 1 established 
(external or internal) 



Initiate setup of parallel internal general call 

CC-INFO 



« MULTI-KEYPAD, 17H + » 

Call transfer request 

CC-INFO 



« MULTI-KEYPAD, '1C 34'H » 
CC-RELEASE 



CC-RELEASE-COM 



r 



For each idle PP < 



r 



Any PP (except PP1) 

attached to the same 
line 



Paging of the idle PP 




CC-SETUP 



CC-ALERTING 



If this PP picks up: 

CC-CONNECT 



For each PP already in use j 
(if the line implements the "Multiple 
calls" feature and is in "multiple call" 



ii 



jcomolete 



CW indication to the PP in use 
CC-INFO 



« CALLING PARTY NUMBER » 

« SIGNAL value = 'CW = '07'H » 

If this PP accepts the waiting call 
CC-INFO 



« "KEYPAD", info = ' 1C35'H » 



Figure 19: Use of 'unannounced call transfer' as a way to re-inject a call into the system 

NOTE 2: The Call Control message sequence in figure 19 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 3: For the sake of simplicity in the figure 19, call information is not shown and independent timelines are 
used on the left and right hand sides. Implementations will follow the messages content and sequence 
described in clauses 7.4.3.6.1 and 7.4.3.6.2. 



7.4.3.6.4 Remote party CLIP on call transfer 

"Remote party CLIP on call transfer" shall be used when a call transfer occurs between the remote parties of a double 
call. It is defined as follows: 

• A first call between a first party (A, transferring party) and a second party (B, "remote" party) is supposed to 
have been completely established. This first call may be external or internal. 
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• A second internal call between A and a third party (C, the PP target of the call transfer) is either already 

established (announced call transfer) or being established (unannounced call transfer). "Remote party CLIP on 
call transfer" shall be used on announced or vmannounced call transfer. 

"Remote party CLIP on call transfer" occurs in the FP after reception of the "call transfer request" from the transferring 
party. The remote party CLIP (of B), if available, shall be indicated by sending the «Calling Party Number» 
information element in a {CC-INFO} message. 

NOTE 1: "Remote party CLIP on call transfer" is appUcable when the third party C is internal (that is, registered to 
the same PP as the transferring party A). 

NOTE 2: C successively receives the usual CLIP (of A) and the "Remote party CLIP on call transfer" (of B). 

NOTE 3: The call transfer target PP will differentiate the remote party CLIP/CNIP on call transfer from the 
CLIP/CNIP on call waiting thanks to the associated call id. 

NOTE 4: If the remote party is external and was the target of an outgoing call, the FP never received a CLIP for 
this party and will have to create an 'artificial' CLIP for it. 

7.4.3.6.5 Remote party CNIP on call transfer 

The "Remote party CLIP on call transfer" procedure applies unchanged, except that CLIP is replaced everywhere with 
"CNIP". 

NOTE 1 : In case both CLIP and CNIP are sent to the PP, it is sufficient to display one of them. It is optional to 
display both. 



FP 




B 

(internal or external) 



C 

(internal) 



call 1 established 



establish parallel internal call 2 
CC-INFO 



« MULTI-KEYPAD, info = '17'H -i- number » 



ring-back tone 
CC-INFO 



SIGNAL value = '01 'H » 
call transfer request 
CC-INFO 



« IVIULTI-KEYPAD, info = '1C 34'H : 




CC-SETUP (see note 4) 



« CALLING PARTY NUMBER » of A 
« CALLING PARTY NAME » of A 

CC-ALERTING 



if announced call transfer 
CC-CONNECT 



if unannounced call transfer 
CC-CONNECT 



Remote party CLIP on call transfer 

CC-INFO (see note 4) 



« CALLING PARTY NUMBER » of B 
«CALLING PARTY NAME » of B 

if unannounced call transfer 
CC-CONNECT 



Call 
pick-up 



Call 
pick-up 



Call 
pick-up 



Figure 20: Remote party CLIP and CNIP on call transfer 
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NOTE 2: The Call Control message sequence in figure 20 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 3: On figure 20, three possible positions for the {CC-CONNECT} message are shown. 

NOTE 4: CNIP for internal handsets is handled according to the provisions of GAP "Internal Call CNIP" procedure 
((GAP)EN 300 444 [12], clause 8.44). 

NOTE 5: CNIP and CLIP might not fit in a single message; in that case one or more additional {CC-INFO} 
message(s) are used. 



7.4.3.7 3-party conference with established external and/or internal calls 

The 3-party conference takes place either between 3 PPs on the same FP (based on 2 internal calls), or between 2 PPs 
and one remote party (based on one internal + one external calls), or between 1 PP and 2 remote parties (based on 
2 external calls). 

If the "Multiple Unes" feature is implemented, the calls may be on two different lines. 
Initiating PP. The "initiating PP" is the PP requesting the conference call. 

In case two parallel calls are estabUshed, one of them being the active call, and in order to establish a conference, the 
initiating PP shall send: 

• a 'conference call request' consisting in the control code ICH as keypad information in a {CC-INFO} message, 
followed by 32H; 

• the call identifier of the on-hold call to be added to the active call in order to estabUsh the conference, in a 
«CALL-1NF0RMAT10N» IE included in the same {CC-INFO} message. 

If there are several calls on hold, the PP shall select one of them (e.g. the former active call could be used) and the FP 
shall support all possible selections. 

NOTE 1 : However, a FP may not accept to create a conference call if there are more than one calls on-hold, as 
described in clause 7.4.3.7.1. 

The call id of the conference shall be chosen by the FP among the involved call ids (either the on-hold call id selected 
by the PP, or the active call id). 

If the conference call estabhshment is successful: 

• the FP shall indicate 'CS idle' call status to the initiating PP, for the call whose call id was not chosen as the 
conference call id; 

• the FP shall indicate 'CS conference connect' call status to all PPs participating in the conference call 
(including the initiating PP), with the chosen conference call id. The FP may send an intercept tone together 
with this call status to some or all of the PPs («SIGNAL» information element with signal value '02'H, 
'intercept tone'); 

• the FP shall issue a 'call identifier update' together with the 'CS conference connect' call status, to all PPs for 
which the call id (of the involved call) is different from the conference call id, as shown on figure 21. 

NOTE 2: For a 3 party conference call as described in the present procedure, there is only one PP at most requiring 
a call id update. More specifically: 

- if the on-hold call id is used as the conference call id, a call id update is sent to the non-initiating party 
involved in the active call, if internal; 

- conversely, if the active call id is used as the conference call id, a call id update is sent to the 
non-initiating party involved in the on-hold call, if internal. 

NOTE 3: In a 3-party conference call, all PPs involved in the conference share the same call identifier for the 
3-party call. 
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The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 

calls"). 

When implementing the "3-party conference" feature, the FP shall set bit a^i of the "Extended higher layer capabilities 
(part 2)" (see EN 300 175-5 [5], clause F.3). 



PP 



FP 



The on-hold call Id shall 
be used in the 
conference call request 



In this example, the FP 
chooses the on-hold call 
id as the conference call 




Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call hold' 
Call id=2, call status = 'CS call connect' 



Conference call request (with on-hold call id) 

CC-INFO 




« MULTI-KEYPAD, info = '1C 32'H » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'on-hold call id' ='01 'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS conference connect' > 



Figure 21 : 3-party conference call establishment request 



ETSI 



84 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



PP1 



FP 



PP2 



The on-hold call id 
shall be used in 
the conference call 
request 



First call established (external or internal) 

Call id=1 , call status = 'CS call hold 




Second call established, (internal), 
with call Id =2, call status = 'CS call connect' 



CC-INFO 



« MULTI-KEYPAD, info = '1C 32'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 
value = 'on-hold call id' ='01 'H > 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 

value = 'active call id ' = '02'H > 

< id type/subtype = 'Call status', 

value = 'CS idle' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 

value = 'on-hold call id' = '01 'H > 

< id type/subtype = 'Call status', 

value = 'CS conference connect' : 




CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 

value = 'current call id' ='02'H > 

< id type = 'Call identifier', 

subtype = 'Updated call identifier', 
value = 'on-hold call id' ='01 'H > 

< id type/subtype = 'Call status', 

value = 'CS conference connect' > 



As the conference call id chosen is the 
on-hold call id, and the non initiating 
party involved in the active call is 
internal, it receives a call id update. 



In this example, the FP 
chooses the on-hold 

call id as the 
conference call id. 



Figure 22: Call id update for the non-initiating PP 



7.4.3.7.1 Unsuccessful 3-party conference call 

If the conference call request is unsuccessful, e.g. because PP is involved in more than 2 calls: 

• the FP shall send a negative acknowledgment as described in clause 7.4.3.4 (call status of the active call 'CS 
call connect' re-sent, along with call status reason 'control code failed'). 

7.4.3.7.2 3-party conference call release 

If the conference call is later transferred from the initiating PP to a target PP (using the call transfer feature [NG1.N.8]) 
the target PP shall play the role of the "initiating PP" in the following sub-sections. 

Release from one of the (non initiating) parties : 

The procedure "Call release and call release rejection" of clause 7.4.3.5.4, can only be used if the PP is involved in a 
conference and in another call (in other words, when the conference is a parallel call) in order to terminate the PP 
participation in one of these calls. In particular, they cannot be used by the FP to notify the PP when one of the remote 
parties hangs up (otherwise, this would exclude the PP from the conference call). 

When one of the (non-initiating) parties hangs up during a 3PTY conference call: 

• the conference call shall become a regular two-end call; 
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• the FP shall send the call status 'CS call connect' to the remaining PP (or PPs) involved in the resulting regular 
2-end call together with the line identifier if the remaining party is external; 

• the FP shall send to the PP (or PPs) the number of the remaining other party in a «CLIP» IE, if this number 
is available; 

NOTE 1 : If the other party is external and was included in the conference call as a result of an outgoing call, the FP 
never received a CLIP for this party and will have to create an 'artificial' CLIP for it. 

• the FP should issue a tone indication to the remaining parties. 

The 'CS idle' call status cannot be used by the FP to notify the PP when one of the remote parties involved in the 
conference hangs up. Sending this call status causes the PP to be excluded from the conference call. 

Release from the 3PTY conference initiating PP: 

When the initiating PP of the conference hangs up during a 3PTY conference call, the conference call shall be released 
when the two other parties are external. If one or more of the other parties is internal, the behaviour is left free to the 
implementation: the conference call may be released or become a regular two-end call between the remaining parties 
(i.e. can be used as an alternate method to perform a simple call transfer procedure). 



PP FP 

<C^^^ ^3-party conference established 

CC-RELEASE 
► 



CC-RELEASE-COM 
4 



Figure 23: 3-party conference release 

If the conference call becomes a regular two-end call, all provisions of the 'Release from one of the (non-initiating) 
parties' subsection regarding the sending of a 'CS call connect' call status, of a CLIP, and of a tone indication to the 

remaining PP (or PPs) apply. 

Release of one of the parties from the 3PTY conference initiating PP: 

Releasing a remote party from the 3PTY conference initiating PP is not systematically possible as there is only one call 
id assigned for the conference call. However, the following behaviour is allowed : 

If the conference call was established in one of the following contexts: 

• either with two external parties on two separate hnes (FP using the multiple hnes features [NG1.N.14]); or 

• with one internal and one external parties; 

then the initiating PP may release a remote party using a parallel call release command with the Une identifier (no call 
identifier sent along). The FP shall support this type of release. 

NOTE 2: In case of PSTN networks, this allows the PP to get rid of a remote party that hanged up and for which the 

network plays an infinite release tone. 

If the conference call becomes a regular two-end call, all provisions of the 'Release from one of the (non-initiating) 
parties' subsection regarding the sending of a 'CS call cormect' call status, of a CLIP, and of a tone indication to the 
remaining PP (or PPs) apply. 
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7.4.3.8 Intrusion call (from PP to FP) 

Intrusion call is a simple way to set up a 3-party conference call, with an existing external active call on another PP. 
This service comes in two procedures, implicit and explicit: 

• 'implicit intrusion call' mimics the usual behavior of two PSTN wired phones cormected to the same physical 
analogue line; 

• 'explicit intrusion call' can be thought of as a menu oriented service allowing intrusion into potentially any call 
active on the system. 

NOTE: Intrusion call is also known as "barging-in". 

A line setting also exists to allow or dis-allow the call intrusion. This setting applies to implicit and exphcit intrusion 
call procedures. 

When implementing the feature, the FP shall set bit i of the "Extended higher layer capabilities (part 2)" 
(see EN 300 175-5 [5], clause F.3). 

7.4.3.8.1 Implicit intrusion call into a line in "single call" mode 

This procedure applies to the FP and to an idle PP on a line configured in "single call" mode. 

NOTE 1: "ImpUcit call intrusion" if implemented should be a configurable feature of the single call mode line. 

If PPl is involved in an active external call and PP2 wishes to participate in a 3-party conference with PPl and the 
remote party: 

• PP2 shall attempt to make an external call, and shall specify the external line to use (possibly 'None') using 
either the {CC-SETUP} or a {CC-INFO}message (see clause 7.4.5.2). Implicit call intrusion shall succeed if 
the following conditions are all met: 

1) the line to use is entirely determined, i.e. PP2 is attached to a single hne or PP2 specifies the line to use 
(i.e. does not use 'None'); 

NOTE 2: If a {CC-INFO} IE is used for PP line selection, the hne is however not known at {CC-SETUP} time (see 
figure 25). 

2) there is already an active call on that hne; 

3) the field 'Multiple calls mode' of the corresponding line settings (see clause 7.4.11.4.8) is set to '30'H 
('Single call mode'); 

4) the field 'Intrusion call' of the corresponding hne settings (see clause 7.4.11.4.9) is set to '3rH 
('allowed'). 

• If the PP line selection is done in the {CC-SETUP} message (see figure 24): 

This message shall be directly acknowledged by the FP with a jCC-CONNECT} message with call 
status 'CS conference connect' and the call identifier of the intruded call. If the intruded call is external, 
the {CC-CONNECT} message shall include the hne id of this call (together with the hne type 
information). 

• If the PP line selection is done in a subsequent {CC-INFO} message (see figure 25): 

After reception of the {CC-SETUP}, the FP shall assign a new call id as for any new outgoing first call 
(e.g. in a { CC-SETUP- ACK} message with call status 'CS call setup ack'). 

As soon as the PP line selection is received, the FP shall acknowledge it with a {CC-CONNECT} 
message, with call status 'CS conference connect' and shall update the call id in the same message to the 
intruded call id value. If the intruded call is external, the {CC-CONNECT} message shall include the 
line id of this call (together with the line type information). 
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• The FP shall notify PPl with a {CC-INFO} message containing: 

the information element «CALL INFORMATION» with the same call identifier and call status; 

if required by the "Tones provision" feature, the information element «SIGNAL» with the value 02H 
indicating 'Intercept tone on'. 

The FP shall generate automatically a conference call audio stream between the three parties. 

Error processing. If conditions 1, 2, 3, and 4 are not all met, the FP shall handle the call as a regular outgoing call. 
More specifically: 

• If conditions 1 is met but condition 2 is not met, the FP shall place the new outgoing call on the (idle) hne. 

• If conditions 1 , 2 are met but condition 3 is not met, the FP shall attempt to place an additional call on the 
multiple call hne if possible; otherwise it shall use procedure 7.4.8.3, "Busy system or hne notification". 

• If conditions 1, 2 and 3 are met but condition 4 is not met, the FP shall always use procedure 7.4.8.3, "Busy 
system or line notification" . 



PP2 

attached to line u 



PPl 

attached to line u 



FP 



Network 



The PR sets up the call 
and selects the line to be 
used (possibly 'None') 



External Call established on line u with call Id 1 



CC-SETUP 
1 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 



CC-CONNECT 

-r 



If required by the Tones provision' feature 



« SIGNAL, value = '02'H » 
« CALL-INFORMATION, 



< id type = 'Line identifier', subtype = 'external', value = 'u'> 

< id type = 'Line identifier', subtype='line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'call Id 1'> 

< id type/subtype = 'Call status', value = 'CS conf. connect'> 



If required by the 'Tones provision' feature 




CC-INFO 



« SIGNAL, value = '02'H » 
PP2 «CALLING-PARTY-NUMBER» 

« CALL-INFORMATION, 

< Identifier type = 'Call identifier'> 

< Identifier subtype = 'Call identifier'> 

< Identifier value = 'call id 1 ' > 

< Identifier type = 'Call status'> 

< Identifier subtype = 'Call status'> 

< Identifier value = CS conf. connect' > 



3-Dartv call establishment 



\ r 

Figure 24: Implicit intrusion call with PP line selection in the {CC-SETUP} 
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PP2 

attached to line u 



PP1 

attached to line u 



FP 



Network 



(The PP selects the line to 
be used (possibly 'None') 




External Call established on line u with call Id 1 



CC-SETUP 
t 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'call Id 2'> 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 
» I 

CC-INFO 



+ 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 



CC-CONNECT 

T 




If required by the 'Tones provision' feature 



« SIGNAL, value = '02'H » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external", value = 'u'> 

< id type='Line identifier', subtype='line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'call id 2'> 

< id type = 'Call identifier', subtype = 'Updated call id', value = 'call id 1'> 

< id type/subtype = 'Call status', value = 'CS conf. connect'> 

CC-INFO 



If required by the 'Tones provision' feature 




« SIGNAL, value = '02'H » 

PP2 «CALLING-PARTY-NUMBER» 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier'> 

< Identifier subtype = 'Call identifier'> 

< Identifier value = 'call id 1 ' > 

< Identifier type = 'Call status'> 

< Identifier subtype = 'Call status'> 

< Identifier value = CS conf. connect' > 

» 



3-Dartv call establishment 




\ r 

Figure 25: Implicit intrusion call with PP line selection in a {CC-INFO} 

NOTE 3: The Call Control message sequence in figure 24 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 4: In addition to the call status 'CS conference connect', CLIP of PP2 sent together with the call id of the 
external call warns PPl of a call intrusion attempt. 

NOTE 5: If the selected hne is not a "single-call" mode line, the DECT system will try to make an outgoing call. 

When the intrusion call is established, the provisions of clause 7.4.3.7, "3-party conference with estabUshed external 
and/or internal calls" apply (including release related provisions). 
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7.4.3.8.2 Explicit intrusion call 

The present procedure applies to the FP, an idle PP (the intruder), and a PP with an active call (the intruded PP). With 
explicit call intrusion, the PP uses a specific control code while initiating the setup of a call, in order to indicate to the 
FP that a call intrusion is attempted. 

There are two available types of explicit call intrusion: handset intrusion and line intrusion. This two types of explicit 
intrusion are exclusive. 

Handset intrusion. When using handset intrusion, the PP uses the terminal id number of the targeted handset to request 
intrusion of the call active on that handset. No line id specification is used (not even 'None'). 

Handset intrusion succeeds if there is an active call on the targeted handset (there can be only one). This active call may 
be external or internal. 

NOTE 1 : Only handset intrusion allows the intrusion of an internal call. 

The FP may forbid handset intrusion if the intruder and intruded PPs not attached to a common Une. 

Special case. It is allowed to use '*' as the target of handset intrusion. Handset intrusion with target '*' succeeds if there 
is one and only one active call (external or internal) in the DECT system. 

Line intrusion. When using line intrusion, the PP uses the line id of the targeted line to request intrusion into an active 
external call on that line. No terminal id number is used (not even '*'). The PP shall not specify a line it is not attached 
to (see clause7.4.5.2.1). 

Line intrusion succeeds if there is a single active external call on the targeted Une. The targeted line may be a single call 
or multiple call line. If a multiple call line, it may be configured in "multiple call" or "single call" mode. 

NOTE 2: Line intrusion only intrude external calls. 

The FP could forbid a call intrusion from a PP not attached to the line of the external call to be intruded 

Special case. It is allowed to use 'None' as the target of line intrusion. Line intrusion with target 'None' succeeds if there 
is one and only one active external call in the DECT system. 

PP and FP compliance with the 'Explicit call intrusion' procedure. 

A PP implementing the present procedure shall implement at least one of the two types of expUcit call intrusion. 
A FP implementing the present procedure shall implement both types of 'explicit call intrusion'. 



ETSI 



90 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



PP2 

intruding PP, 
attached to line u 



Handset intrusion 

Internal or external calls 



OB 

I Line intrusion 

External calls 



PP1 In a call 

intruded PP, 
attached to line u 



CC-SETUP 



FP 



Networic 



Ongoing external call with call id 1 



+ 



« MULTI-KEYPAD, < Keypad info : 
I 

CC-INFO 
1 



'1C40'H> » 



« MULTI-KEYPAD, < Keypad info = '17xx'H> » 



« CALL- IN FORMATION, 

< Identifier type = 'Line identifier^ 

< Identifier subtype = 'Line identifier for external calls'> 

< Identifier value = 'u' > 



CC-CONNECT 

i- 



If required by the 'Tones provision' feature « SIGNAL, value = '02'H » 



XX can be a terminal id 
number, or '*' as a 
special case 



The line id value may be 
'None' as a special case 



— -t- 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external', value = 'u'> 

< id type = 'Line identifier', subtype='line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'call id 1'> 

< id type/subtype = 'Call status', value = 'CS conf. connect'> 

» 



If required by the 'Tones provision' feature 



CC-INFO 



« SIGNAL, value = '02'H » 



PP2 «CALLING-PARTY-NUMBER» 

« CALL-INFORMATION, | 

< id type/subtype = 'Call identifier', value = 'call id 1'> 

< id type/subtype = 'Call status', value = 'CS conf. connect'> 



3-party call establishment 



Figure 26: Successful explicit call intrusion 



NOTE 3: The Call Control message sequence in figure 26 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 
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If PPl is involved in an active call and PP2 wishes to participate in a 3-party conference with PPl and the remote party: 

• PP2 shall insert a call intrusion request, consisting in the control code ICH followed by 40H in the 
{CC-SETUP}message. 

• PP2 shall then use one of two explicit intrusion use cases: 

1. Handset intrusion. PP2 sends the terminal id number of the handset owning the targeted call (external or 
internal), or '*' in order to intrude any handset, in the {CC-SETUP} or in a subsequent {CC-INFO} 
message. PP2 does not send any line specification (not even the 'None' value). 

■ If '*' is not used and there is a call active on the specified terminal, this call (external or internal) 
shall be intruded. 

■ If '*' is used and there is a single active call (external or internal) in the system, this only call shall 
be intruded. 

2. Line intrusion. PP2 sends the line id of the targeted external call {without any terminal id number) in the 
{CC-SETUP} or in a subsequent {CC-INFO} message. 

■ If 'None' is not used and there is a single active external call on the specified line, this only call 
shall be intruded. 

■ If 'None' is used, and there is a single active external call on the DECT system, this only call shall 
be intruded. 

• The FP shall answer the intruder (PP2) with a { CC-CONNECT} message including: 

a «CALL 1NF0RMAT10N» IE containing: 

■ the call id of the intruded call, and the call status "CS conference connect", 

■ if the intruded call is external and the line id was not specified by the PP (handset intrusion, or hne 
intrusion with 'None'), this IE shall also contain the intruded call line id. 

if required by the "Tones provision" feature, the «SIGNAL» IE with the value 02H indicating 
'Intercept tone on'. 

• The FP shall notify the intruded PP (PPl) of the intrusion with a {CC-INFO} message containing: 

a «CALL 1NF0RMAT10N» IE containing the call id of the intruded call, and the call status "CS 
conference connect", 

if required by the "Tones provision" feature, the «SIGNAL» IE with the value 02H indicating 
'Intercept tone on'. 

The FP shall generate automatically a conference call audio stream between the three parties. 

NOTE 4: In addition to the call status 'CS conference connect', CLIP of PP2 sent together with the call id of the 
external call warns PPl of a call intrusion attempt. 

NOTE 5: In "multiple call" mode, simply initiating a call setup would lead to the setup of an additional call if the 
line can accept an additional call, or to a failure (busy tone signal received back). 

When the call intrusion is established, the provisions of clause 7.4.3.7, "3-party conference with estabhshed external 
and/or internal calls" apply (including release related provisions). 

Error processing. In all other cases, that is: 

• for handset intrusion: 

if there is no external or internal call active on the specified handset; 

if '*' is used, if there is no external or internal call active (or more than one) in the system; or 

the call to be intruded is external, and the field 'Intrusion call' of the corresponding line settings (see 
clause 7.4.11.4.9) is set to '30'H ('not allowed'); 
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• for line intrusion: 

if there is no external call or more than one external call on the specified line; 

if 'None' is used, if there is no external active call (or more than one) in the system; 

if the PP is not attached to the intruded line; or 

the field 'Intrusion call' of the corresponding line settings (see clause 7.4.1 1.4.9) is set to '30'H ('not 
allowed'). 

• the FP shall use the "Busy system or line notification" procedure of clause 7.4.8.3, that is: 

the FP shall send call status 'CS call disconnecting' along with call status reason 'control code failed'; 

the FP shall send a «CALL INFORMATION» IE with call status 'CS idle' in order to fi-ee the call id 
(on the intruding PP side only). 

7.4.3.9 Internal call codec priority 
7.4.3.9.1 Description 

When performing an internal call between two wideband enabled PPs, the FP shall arrange that the call is finally 
established in a wideband codec rather than in a narrow band codec. Respectively in a super wideband codec rather than 
in a wideband or narrowband codec. 

As a consequence, in the particular case where both PPs present G.722 with highest priority, the internal call shall 
finally be established in ITU-T Recommendation G.722 [17]. 

Exception cases to this procedure are listed in clause 7.4.3.9.2. 

This procedure has been added to guarantee that the internal call will be established in the highest audio quality 
supported by both handsets involved in the internal call, at least when no other call is established at the same time in the 
DECT system. 

Two examples of support of this procedure are given hereafter: 

EXAMPLE 1: When the «Codec List» information element is only specified at subscription registration and 
location registration phases. 

EXAMPLE 2: When the «Codec List» information element is specified at call setup phase. 

Figure 27 shows an example (example 1) with an internal call sequence where no codec list is specified at call setup and 
both PP-s support wideband (same codec hst re-used as at location registration phase). 
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PP1 FP 

ACCESS RIGHTS-REQUEST 



PP2 



« Codec List = G. 722,..., G.726» 

ACCESS RIGHTS ACCEPT 



« Codec List G.722,...,G.726» 
LOCATE-REQUEST 



« Codec List = G.722,...,G.726» ^ 
LOCATE-ACCEPT 



« Codec List = G.722,...,G.726» 
Initiate an internal call 



CC-SETUP 


► 


«Basic Service=98» 




CC-CALL-PROC 









CC-CONNECT 




«Codec List = G.722» 



LCE_REQUEST_PAGE (long) 



CC-SETUP 



«Basic Service=98» 

CC-CONNECT 



«Codec List = G.722» 
CC-CONNECT-ACK 



Figure 27: Internal call with no codec list at call setup 

Figure 28 shows example 2 with an internal call sequence where the codec Ust is specified at call setup and both PPs 
support wideband. 



PP1 



FP 



PP2 



CC-SETUP 


LCE_REQUEST_PAGE (long) ^ 


► 

«Basic Service=98» 

«Codec List-G.722, G726» 

CC-CALL-PROC 


CC-SETUP 


M 

CC-CONNECT 


► 

«Basic Service=98» 

«Codec List=G.722, G726» 

CC-CONNECT 


^ 

«Codec List = G.722» 

CC-CONNECT-ACK 


< 

«Codec List = G.722» 


► 



Figure 28: Internal call with codec list at call setup 
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NOTE: The Call Control message sequences in figures 26 and 27 should be understood as examples. The real 

sequences may also contain different Call Control messages or Call Control messages in another order or 
Call Control messages with other contents. 

7.4.3.9.2 Exception cases 

The following exceptions to the clause 7.4.3.9 shall apply: no requirement appUes in the following cases: 

a) Case of internal call transfer. In this case, the PP requesting the transfer may specify any order for the codecs 
in the «Codec List» information element. For example, the codec used in the initial ongoing external call to 
be transferred may be given the highest priority in the «Codec List» information element sent by the PP for 
the parallel call. This could avoid two codec switching: one for each PP involved in the transfer. 

b) Cases of multiple calls handled by the FP at the same time, if critical for FP hardware resources. 

c) Specific implementations of PPs that have to support narrow band headsets. 

d) Specific implementations of PPs where battery autonomy is very critical. 

7.4.3.10 Handling of lines where second calls are signalled in-band 

The present procedure describes the 'Handling of lines where second calls are signalled in-band' feature. In other words 
it describes the rules specifically applicable to hnes supporting'double calls with in-band signalling' (DCIBS lines for 
short). Most notably, PSTN Unes implementing 'PSTN double calls' are DCIBS Unes, and possibly other types of Unes 
implementing similar rules. 

The present procedure describes the use by the PP and FP of a limited subset of the procedures of clause 7.4.3.5, 
"Common parallel call procedures", with some adjustements, so that they can be used with 'double call with in-band 
signalling' lines. 

The PP shall support the 'Handling of lines where second calls are signalled in-band' feature additionally to the parallel 
calls relating features. However the present procedure is designed so that the PP behavior will be very close the its 
behavior on regular Unes. The PP is informed of the type of line through the 'Une type information' sent along with the 
line identifier. 

The FP may support the feature depending on the type of lines it is designed to be connected to. A FP could be designed 
to support only DCIBS lines and is allowed in that case not to support all common parallel call procedures (see 
7.4.3.10.3.1 for more details). However the features and procedures to be supported in that case rely heavily on the 
corresponding features for regular lines with as few adjustments as possible. 

On the contrary, the handhng of a first call on such hnes does not require any modification of these procedures. This 
includes cases where the PP is idle when handhng this first call, or already involved in a call but on another Une. 

7.4.3.10.1 General requirements 

Double calls with in-band signalling: A 'double call with in-band signalling' (DCIBS) line is a legacy line on which 
second calls-incoming or outgoing- are handled using signalling 'in-band'. On such lines, the DECT FP has to send 
legacy network messages with hmited semantics for handling second calls-incoming or outgoing. As a result: 

• The Network only delivers in-band tone-based messages targeted at the user (i.e. unvisible to the FP and PP). 

• For some 'double call with in-band signalling lines' however, the network dehvers an off-hook CLIP (see 
clause 3.1) in case of call waiting (or 'CLIP on call waiting') which allows the FP to be aware of the waiting 
call. This leads to the following two subtypes of 'double call with in-band signalling' Unes, which can be 
distinguished by the way they handle second calls: 

Basic 'double call with in-band signalling' lines: Line not supporting double calls, or supporting them 
but NOT deUvering any off-hook CLIP for a waiting call. Such Unes are considered as fully 'common 
parallel call' compliant lines, because the possibility of a second call on such lines is ignored from Part 3 
perspective (although the use of transparent commands for handling them is still possible) and are 
handled in clause 7.4.3.10.2. 
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Off-hook CLIP enabled 'double call with in-band signalling' lines: Line supporting classical double 
call' procedures and delivering an off-hook CLIP in case of call waiting. Such lines are handled in 
clause 7.4.3.10.3. 

NOTE 1: Both subtypes of 'double call with in-band signalling' Unes are 'single call mode' lines. 

PP notification of the line type: The FP shall indicate whether the Une is a 'double call with in-band signalhng' 
(DCIBS) Une or not, using the 'second call type' flag (bit 2) of the 'Une type information'. Bit 2 set to T indicates a 
DCIBS line. 

NOTE 2: The 'line type information' is a line identifier of subtype 'line type information' sent together with the line 
id from FP to PP. It also includes the 'network delay type' flag. See clauses 7.4.3.5.1, 7.4.3.5.2 and 
7.4.5. L 

NOTE 3: Although a PSTN line is usually a DCIBS line, an enhanced FP may choose to handle a given PSTN line 
with the 'common parallel call procedures' if it is possible (e.g. by using a tone detector). In that case, the 
'Handling of second call line' feature is not used (line type information 'OO'B). 

Transparent network-directed commands: Transparent 'network directed' cormnands issued by the PP are not the 
main target of the present procedure, but are however dealt with in clause 7.4.3.10.4, as they can still be used to handle 
calls on such lines. Transparent conmiands generally use the 'R' key (coded as keypad information 15H) as the unique 
control code. 



7.4.3.1 0.2 Basic 'double call with in-band signalling' lines 

Basic 'double call with in-band signalling' lines: A basic double caU with in-band signalUng line (basic DCIBS line) 
is a DCIBS line not supporting double caUs, or supporting them but NOT deUvering any off-hook CLIP for a waiting 
call. 

NOTE I: A call waiting indication on such a Une, being fully in-band, may be lost if the handset using this Une is 
involved in a call on another Une, (neither heard by the user, nor detected by the FP). 

A basic DCIBS line shall be handled as a line only allowing a single call context from the 'Common parallel call 
procedures' point of view. More specifically: 

• The 'Common paraUel call' procedures shaU not apply for handling second calls. In other words, the FP shaU 
handle the line as if it was not supporting double calls. In particular: 

In case an 'outgoing parallel call initiation' (see clause 7.4.3.5.1) is attempted on such a line, the 
procedure 'Busy system or line notification' of clause 7.4.8.3 shall be used by the FP. 

The 'call waiting indication' procedure (see clause 7.4.3.5.2) shaU not be used. 

NOTE 2: As the FP is not aware of waiting call on such lines, incoming second calls handling cannot use the 
'Cormnon parallel call procedures'. For the overall consistency of call handling on such lines, these 
procedures are neither used for outgoing second caUs. 

• Classical 'Double call' if available on the Une shall be handled by the user with transparent network directed 
commands from PP to network and shall not be handled through 'Common paraUel call' procedures. 

• The FP shall only assign a call id for the first call on that Une. 

NOTE 3: 'Common parallel caU' procedures stiU apply in multiple Une context for commands involving several 
Unes (e.g. caU toggle to-and-fro a basic double call with in-band signalling' Une). 

Line type information. A basic DCIBS Une shall respect the foUowing rule for the Une type information value: 

• 'Second call type' = 'SCT' = 'O'B, indicating that second calls are handled in a way compUant with 'common 
paraUel call procedures'. 

NOTE 4: As only a single call context is considered on such lines, the behavior of the PP and FP is fully compUant 
with the 'Common parallel call' procedures (no second call is considered). 
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7.4.3.1 0.3 Off-hook CLIP enabled 'double call with in-band signalling' lines 

7.4.3.10.3.1 General requirements for off-hook CLIP enabled 'double call with in-band signalling' 

lines 

Off-hook CLIP enabled 'double caU with in-band signalUng' lines: A 'Off-hook CLIP enabled DCIBS Une' is a 
DCIBS line supporting classical 'double call' procedures and delivering a off-hook CLIP in case of call waiting. For 
such lines: 

Second call handling, call statuses and call id. For off -hook CLIP enabled DCIBS lines: 

• For the handling of second calls, the PP shall use commands comphant with the 'Common parallel call 
procedures' (see clause 7.4.3.5). 

• In particular, a call id shall be assigned in case of second call (incoming or outgoing). 

• It is allowed for the FP to send the call statuses 'CS call hold' and 'CS call connect' at a time not exactly related 
to the corresponding event in the network (if any). 

• Call statuses other than'CS call hold' and 'CS call connect' may not always be available. Use of a 'tone detector' 
on FP side may enhance the set of call statuses the FP is able to send to the PP. 

Remote party hangup in case of second call. In case a remote party hangs up one of two parallel calls, the FP may not 

be aware of this event occurring in the network. As a result it may maintain both call contexts and not warn the PP 
(although the user himself may sometimes be aware of this event through the heard tone). Consequently: 

• the PP may maintain a superfluous second call context (and call id) until it hangs up itself, thus preventing the 
PP to accept or place a second call on the line: 

Issue 1: In that case, the user of the PP could be faced either with one of the two call contexts leading to 
an unexisting call, or with two equivalent call contexts (both handling the same call). 

• However, the FP may later on be indirectly informed of the call release in the network, when either a new call 
waiting occurs, or in case the user initiates an outgoing second call (both events indicating that there were no 
two calls any longer on the line). In that case, the FP shall release the superfluous call context (CS idle with 
call id sent to the PP). This behavior is called a 'late release' of the call (see clause 3.1). 

• In some cases however, the FP may not be able to know which of the two existing call contexts must be 
deleted and shall choose one of the two contexts (e.g. the most probable one) and delete it: 

Issue 2: In that case the user may be faced with a call context showing wrong data. 

• The PP shall use its best endeavour to minimise the inconvenience caused by these issues for the user. 
Clause C.9.1 details some use cases illustrating these issues. 

Translation of conunands into the network. The FP shall use its best endeavour to translate the requests issued as part 
of the 'Common parallel call procedures' into legacy commands understandable by the network. 

NOTE 1 : This does not mean that the PP should forbid the use by the user of legacy connmands directly targeting 
the network. 

Line type information. An 'off-hook CLIP enabled DCIBS hne' line shall respect the following rules for the line type 

information value: 

• The 'Network delay type ('NDT') should be 'O'B, indicating that the line is a 'low delay' hne; however the use 
of procedure 'Off-hook CLIP enabled double call with in-band signalling' lines' for lines with significant delay 
(NDT = 1) is still possible. 

• 'Second call type' = 'SCT' = 'I'B, indicating that second calls are handled (mostly) with in-band signalling. 
NOTE 2: On such lines, call waiting indications are not received in-band by the FP. 

EXAMPLE 1 : An off-hook CLIP enabled PSTN line uses hne type information 'lO'B ('Off-hook CLIP enabled 
DCIBS' line with low delay). 
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EXAMPLE 2: AVoIP line mimicking the PSTN line behaviour including off-hook CLIP would use line type 
information 'll'B ('Off-hook CLIP enabled DCIBS' line with significant delay). 

7.4.3.10.3.2 Applicable procedures and control codes 

Table 18 lists the restrictions and modifications that apply for a FP when handling an off-hook CLIP enabled DCIBS 
line (described in clause 7.4.3.10.3). In case a FP only supports such lines, the amended procedures only apply. 



Table 18: Restrictions applying to a FP when handling an off-hook CLIP enabled DCIBS line 



Feature 


Procedure 


Reference 


Comment 


Parallel Calls 




NG1.N.6 




Control messages 


7.4.3.2 


Amended by 7.4.3.10.3.2 (table 19) 


Common parallel call 
procedures 




NG1.N.7 




Call release and call release 

rejection 


clause 7.4.3.5.4 


Network support unlikely in case of 
parallel calls on DCIBS lines. In case 
of two parallel calls, the FP may 
answer directly 'control code failed' 


Call waiting rejection 


clause 7.4.3.5.7 


Putting a call on-hold 


clause 7.4.3.5.8 


Resuming a call put on-hold 


clause 7.4.3.5.9 


Call transfer 




NG1.N.8 


Amended by clause 7.4.3.10.3.6 


3-party conference call 




NG1.N.9 


Amended by clause 7.4.3.10.3.7 


Call identification (and 
call statuses) 




NG1.N.13 


Amended by clause 7.4.3.10 and 
subclauses 



Applicable control codes. Table 19 lists the restrictions and modifications that apply to control codes handling by a FP 
in case of off-hook CLIP enabled DCIBS line (described in clause 7.4.3.10.3). Other control codes apply with no 
change. When appUcable, the FP shall translate commands into transparent network directed commands. 

In case a FP only supports such Unes, the amended procedures only shall apply (see also clause 6.10, table 9, note 2). 



Table 19: Control messages for control of parallel calls 



Procedure 


Control message 


Direction 


Comment 


Call release (of the indicated call) 


1CH 33H 


PP to FP 


See notes 1 & 2 


Call transfer request (external or internal) 


1CH34H 


PP to FP 


See note 3 


Call waiting rejection 


1CH 36H 


PP to FP 


See notes 1 & 2 


Putting a call on-hold 


1CH 41H 


PP to FP 


See notes 1 & 4 


Resuming a call put on-hold 


1CH 42H 


PP to FP 


See notes 1 & 4 


NOTE 1 : For a parallel call, the FP shall answer with a negative acknowledgement 'control code failed' if the 

command is not supported by the network. 
NOTE 2: The 'CS idle' control code shall be sent to the PP even if the command is not supported by the network. 
NOTE 3: In case there are two calls on the off-hook CLIP enabled DCIBS line, the FP should answer the call transfer 

request with a negative acknowledgement 'control code failed' (see clause 7.4.3.10.3.6). 
NOTE 4; This control code is optional for the PP. 



7.4.3.10.3.3 Parallel calls within a 'off-hook CLIP enabled DCIBS' line 

There can be only two parallel calls within an 'Off-hook CLIP enabled DCIBS' line. The present procedure handles use 
cases with both call on the same 'Off-hook CLIP enabled DCIBS line': these use cases may require a special handing in 
some cases (adjustements of the 'Common parallel call procedures' of clause 7.4.3.5) and are therefore described in 
detail in the present clause. 

NOTE: Two call use cases with two hues, and one call on each hne (whatever the type of these lines) do not 
involve second calls and therefore do not deserve any specific handUng (they are compliant with the 
'Conmon parallel call procedures' of clause 7.4.3.5). 

7.4.3.10.3.3.1 Outgoing parallel call initiation within an off-hook CLIP enabled DCIBS line 

This procedure applies to a 'Off-hook CLIP enabled DCIBS' line on which a first call has already been placed, and a PP 
busy with another call going on on the same line. 
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Outgoing parallel call initiation. When the FP receives an outgoing parallel call initiation from the PP (external or 
internal), it shall use the 'Outgoing parallel call initiation' procedure of clause 7.4.3.5.1. In particular, the FP shall: 

• assign a second call id for new outgoing call, and notify it to the PP. 

• send a 'FP line confirmation' with the appropriated 'line type information' (see clause 7.4.3.10.3.1). 

The FP shall use its best endeavour to translate the "outgoing parallel call initiation" into network directed commands. 

7.4.3.10.3.3.2 Call waiting indication/acceptation/rejection within an off-hook CLIP enabled DCIBS 

line 

This procedure applies to an 'Off-hook CLIP enabled DCIBS' line, a call waiting on that line, and a PP busy with the 
first call on the same line. 

Call waiting indication. When the FP receives an off-hook CLIP from the network indicating an incoming second call, 
the FP shall: 

• assign a new call id for the waiting call; 

• send a call waiting indication to the PP as defined in clause 7.4.3.5.2 (i.e. including CLIP and/or CNIP, newly 
assigned call id for the second incoming call, and 'CS call setup' call status). 

Call waiting acceptation. The call waiting acceptation shall always use procedure 'Call waiting acceptation (from PP to 

FP)' of clause 7.4.3.5.6, with the following modification: 

• call statuses 'CS call hold' for the former active call, and 'CS call connect' for the newly accepted waiting call, 
although they shall still be sent, and sent in this order, may be sent by the FP not at the exact times when the 
corresponding events occurred in the network. 

The FP shall use its best endeavour to translate the call waiting acceptation into network directed commands. 
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If required by the 'Tones 
Drovision' feature 



PP 

1^ 



FP 



External call 1 (with call Id 1) currently In use by PP 



Call waiting indication 

CC-INFO 




« Sl^^^gly^^gj^^ng tone' = '07'H » 

« CALLING PARTY NUMBER, < Calling Party Address = c 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type = 'Line identifier', subtype='line type information', 

< id type/subtype = 'Call identifier', value = 'waiting call id' 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

Call waiting acceptation 

CC-INFO 



illing number' > » 

= 'waiting call line id' > 
value = '1y'B> 
02'H > 



« MULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORMATION, 
< id type = 'Call identifier', value = 'waiting call Id' = '02'H> 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call Identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call fiold' 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 



Off-hook CLIP 



Translation of the 'CW 
acceptation' into a 
network directed 
command 



Immediate sending 
of call statuses, 

independently of any 
network feedback 
(success assumed) 



Figure 29: Call waiting acceptation within an 'off-hook CLIP enabled DCIBS' line 

Call waiting rejection. The call waiting rejection shall always use procedure 'Call waiting rejection (from PP to FP)' of 
clause 7.4.3.5.7. 

NOTE: The call status 'CS idle' to the PP indicates that the waiting call context on PP side has to be deleted, but 
may not be related to the time when the waiting call indication from the network terminates. 

The FP shall use its best endeavour to translate the call waiting rejection into network directed conmiands if this is 
possible. 



7.4.3.1 0.3.3.3 Call toggle within an off-hook CLIP enabled DCIBS line 

This procedure applies to a 'Off-hook CLIP enabled DCIBS' hne with two existing calls, and a PP busy with one of the 
calls on that line. 

Call toggle request. The call toggle request shall always use procedure 'Call toggle (external or internal)' of 
clause 7.4.3.5.3, with the following modification: 

• call statuses 'CS call hold' for the former active call, and 'CS call cormect' for the newly active call, although 
they shall still be sent, and sent in this order, may be sent by the FP not at the exact times when the 
corresponding events occurred in the network. 

The FP shall use its best endeavour to translate the call toggle request into network directed commands. 
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7.4.3.10.3.3.4 Active call release with replacement within an off-hook CLIP enabled DCIBS line 

Active call release request with replacement. This request shall always use procedure 'Active call release with 
replacement (from PP to FP)' of clause 7.4.3.5.12, with the following modification: 

• call statuses 'CS idle' for the former active call, and 'CS call connect' for the newly active call, although they 
shall still be sent, and sent in this order, may be sent by the FP not at the exact times when the call replacement 
occurs in the network. 

The FP shall use its best endeavour to translate the "active call release with replacement" request into network directed 
commands. 

7.4.3.10.3.4 Parallel calls away from an off-hook CLIP enabled DCIBS line 

This procedme applies to a handset involved in call 'a' on line A ('Off-hook CLIP enabled DCIBS' line) and leaving this 
call and line in order to: 

1) either place a new call on another line B (outgoing parallel call initiation); 

3) connect an existing call on another line B (call toggle, call waiting acceptation); or 

4) connect an existing call on another Une B while releasing the active call (active call release with replacement). 



Table 20: Call status to be sent for call a 



Procedure 


Clause 


Message from FP to PP 


Single call use case 

Call a active on line A 


Two calls use cases 

Call a active on line A 
Call & on-hold on line A 


Outgoing parallel call initiation (extemal or internal) 


7.4.3.5.1 


CS call hold (call a) 


CS call hold (call a) (note 1) 


Call toggle (extemal or internal) 


7.4.3.5.3 


CS call hold (call a) 


CS call hold (call a) (note 1) 


Call waiting acceptation (from PP to FP) 


7.4.3.5.6 


CS call hold (call a) 


CS call hold (call a) (note 1) 


Active call release with replacement (from PP to FP) 


7.4.3.5.12 


CC-RELEASE 


CS idle (call a), or CS call 
hold (call a) (note 2) 


NOTE 1 : After the handset has left the line, both calls a and b shall be considered on-hold from the PP and user 

perspective, although call a may remain active (but not currently in use) on network side; in that case, the 
FP should play an on-hold music toward the network in order to inform the remote party. 

NOTE 2: The FP may not be able to perform a partial release towards the network for call a; in that case the FP shall 
still partially fulfil the request: 'CS call hold' shall be sent for call a with call status reason 'control code failed'. 
Note that the overall result of the request in that case is similar to a call toggle (but with a 'call status reason' 
sent for call a due to the partial failure). 



7.4.3.10.3.5 Parallel calls towards an off-hook CLIP enabled DCIBS line 

This procedure applies to an 'Off-hook CLIP enabled DCIBS' line (line A), and to a handset involved in a call on 
another line, or in an internal call, and leaving this line or internal call in order to be coimected to call a on line A. 

NOTE 1: Call 'a' may be created by the handset, or be a previouly existing call owned by the handset. 

NOTE 2: There may be or not another call 'b' on line A. 
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Table 21 : Call status to be sent to the handset for call a 



Procedure 


Ciause 


lUlessage from FP to PP 

Call a and b are both on targeted line A 
Call a is the call targeted by the procedure 


rroceaures aauing a can (new aciive caii^ lo ine 
nanasei 




Single caii use case 

Call a to be created 


Two caiis use cases 

Call a to be created 

Call b on-hold (see note 1) 


Outgoing parallel call initiation (external or internal) 


7.4.3.5.1 


CS call connect (call a) 
See notes 2 and 3 


CS call connect (call a) 
See notes 2 and 4 


Call waiting acceptation (from PP to FP) 


7.4.3.5.6 


Active call release with replacement (by call waiting) 


7.4.3.5.12 


Procedures changing the active caii on the 
handset 




Singie caii use case 

Call a on-hold (note 1) 


Two caiis use cases 

Call a and b on-hold (note 1 ) 


Call toggle (external or internal) 


7.4.3.5.3 


CS call connect (call a) 
See note 5 


Active call release with replacement (by call on-hold) 


7.4.3.5.12 


NOTE 1 : The indicated status is from handset point of view here. On network side, the call indicated as on-hold to the 
PP may remain active. 

NOTE 2: The FP may send the 'CS call connect' call status before end-to-end connection (e.g. as soon as it receives 
the first keypad information), as it may have no information from the network (see also clause 7.4.3.10.3.1). 
NOTE 3: Procedures of clauses 7.4.3.5.1 , 7.4.3.5.6 and 7.4.3.5.12 are used here for a first call on line A (outgoing or 

incoming). 

NOTE 4: An appropriate translation of the request into network directed commands shall be carried out. 
NOTE 5: If call a was active on network side, the FP shall switch off the on-hold music if used, and no translation into 
the network shall be used. Otherwise, note 4 applies. 



7.4.3.10.3.6 Call transfer 

This procedure applies to PP sending a 'call transfer request' in order to transfer an external call (announced or 
unaimoimced) on a DCIBS line to another PP. 

The procedure 'Call transfer' of clause 7.4.3.6 applies, with the following modifications: 

• If there are two calls on the DCIBS line, the FP should refuse the transfer of one of these calls, and send a 
negative acknowledgment. 

NOTE: In case there are two calls on a DCIBS lines, both calls should be transferred, as they can only be handled 
by a single PP (single call line). However the user may not want to transfer both calls, and the transfer of 
two calls is not defined. 

• In case of waiting call on the DCIBS line after a call transfer to a PP not attached to that line, the call waiting 
indication should however be sent that PP, as if it was attached to the line. 

7.4.3.10.3.7 3-party conference call 

This procedure applies to PP involved in two parallel calls, one of them being the active call, and one of them at least 
being on line A (an 'Off-hook CLIP enabled DCIBS' line), and sending a conference call request. 

The procedure '3-party conference with established external and/or internal calls' of clause 7.4.3.7 apphes, with the 
modifications described in table 22. 



Table 22: Call statuses following a conference call request 



Procedure 


Ciause 


iUiessage from FP to PP 

The conference call is established from call a and b 
Call a at least is on line A 






Caii a and b on line A 


Call a on line A 

Call b on another line, or 

internai 


3-party Conference with established Internal and 
external calls 


7.4.3.7 


CS idle (call b) and 
CS conf. connect (call a) 
(notes 1, 2, 3 and 4) 


CS idle (call b) and 

CS conf. connect (call a) 

(note 2) 


Unsuccessful 3-party conference call 


7.4.3.7.1 


CS call connect 
(previously active call) 
(note 5) 


FP originating failure 

CS call connect (previously 
active call) 
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3-party conference call release 

(Conference call changed into a regular two-end call, 

or fully released) 


7.4.3.7.2 


Not applicable in case of 
remote party hangup. 
Otherwise (PP hangup): 
CS idle (call a) (note 2) 


Applicable in case of remote 
party hangup at the handset 
initiative (see subsection 
'Release of one of the parties 
from the 3PTY conference 
initiating PP') 


NOTE 1 : Call statuses 'CS idle' for the released call, and 'CS conference connect' for the new conference, shall still be 
sent by the FP, and sent in this order, but may be sent not at the exact time when the conference is established 

in the network. 

NOTE 2: The hypothesis here is that call id of call a was reused for the conference. 

NOTE 3: An appropriate translation of the request into network directed commands shall be carried out. 

NOTE 4: As there is a single PP involved in this use case, no call id update is needed. 

NOTE 5: The conference call establishment failed in the network. The failure may not be detected by the FP. In that case 
no call status shall be sent back to the PP. 



7.4.3.1 0.4 Use of transparent commands on DCIBS lines (Basic or Off-hook CLIP enabled) 
or any other line 

This procedure applies to a PP using transparent commands as keypad information towards the FP in order to handle 
parallel calls on a DCIBS line or any other type of Une. 

NOTE 1: DCIBS lines are known to be manageable through the use of transparent commands. 

NOTE 2: The feature 'Handling of lines where second calls are signalled in-band' Unes discourages the use of 

transparent commands with off-hook CLIP enabled DCIBS lines. But transparent commands are the only 
way to handle double calls on basic DCIBS lines. 

NOTE 3: Transparent conmiands are especially useful for GAP or Part 1 PPs, and should not be used by Part 3 PPs, 
unless the user directly enters theses commands on the keypad (e.g. instead of using Part 3 dedicated 
menus). The use of transparent commands towards a Une (especially a non DCIBS line) is not guaranteed 
to have any effect in general. 

Transparent commands. Keypad information sent to the FP when no call is currently processed with the 'Common 
parallel call procedures'. Transparent commands consist in keypad information sent in one or several 
«MULTI-KEYPAD» information element sent in as many {CC-INFO} messages. 

NOTE 4: Keypad information sent by a Part 3 PP may also be sent as part of the 'Common parallel call procedures' 
when a call is being processed. Such keypad information is not considered as transparent connmand. 

EXAMPLE: The digits of the called number sent as part of the 'outgoing parallel call initiation', being part of a 
'cormnon parallel call' procedure, are not considered as a transparent commands, although they are 
forwarded to the network. 

Transparent commands shall be sent to the FP with the call id of the currently active call (by definition, no call is 
currently being processed with the 'Common parallel call procedures' when a transparent command is sent). 

As a result, the used {CC-INFO} messages shall always contain a «CALL-INFORMATION» IE. 

When the currently active call is on a DCIBS line, the FP shall not translate/modify the transparent commands received 
from the PP when relaying them to the (ISBC) network. 
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PP 



Transparent 
outgoing 
parallel call 
initiation 




Existing call 1 witli call id 1 on PSTN line 
Handset busy with call 1 

CC-INFO 




« MULTI-KEYPAD, < Keypad info = '15' H > » 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = '01 'H> » 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = '01 'H> » 



Figure 30: Example of use of transparent commands (with call id of current call) 



Handling of single call services 



7.4.4 

7.4.4.1 Control messages 

The following control codes shall be transmitted as keypad information in {CC-INFO} messages and shall trigger the 
corresponding actions in the FP. 



7.4.4.1.1 



Call deflection control messages 
Table 23: Control messages for control of single call services 



Procedure 


Control message 


Direction 


PT Status 


FT Status 


Gall deflection (to internal) 


1 CH 39H 1 7H + terminal id number 


PP to FP 


C2301 


C2302 


Call deflection (to external) 


1CH 39H 15H + number 


PP to FP 


C2301 


C2302 


C2301 : If FT implements call deflection feature [NG1 .N.11] THEN "M" ELSE "1". 

C2302: If FT innplements call deflection feature [NGI .N.11] THEN "M" ELSE minimum requirement of 

"negative acknowledgement" with call status reason 'control code not supported' (see clause 7.4.3.4). 



Call deflection procedure for internal and external calls is detailed in clause 7.4.4.2. 

7.4.4.2 Call deflection 

When implementing the feature, the FP shall set bit ajj of the "Extended higher layer capabiUties (part 2)" 
(see EN 300 175-5 [5], clause F.3). 

The call deflection service enables the user to respond to an incoming call (external or internal) by requesting 
redirection of this call to another number specified in the response. The call deflection service can only be requested 
before the connection is established by the user, i.e. in response to the incoming call during the period that the user is 
being alerted of the caU (see TS 122 072 [22]). 

Call deflection request. In order to deflect a call with "CS call setup" call status, the PP shall send a 'call deflection 
request' consisting in the control code ICH as keypad information in a {CC-INFO} message, followed by 39H and by 
the deflected-to telephone number (external or internal). The deflected-to telephone number shall be preceded by 15H if 
external or by 17H if internal. 

NOTE 1: A first incoming call, or a call waiting can be deflected. 

As a result of successful call deflection to an internal number, the incoming call (external or internal) shall only 
presented to the deflected-to terminal. In case of external incoming call, the deflected-to terminal may be attached to the 
line of the call (it continues presenting the call, but alone) or not attached to that line (it starts presenting the call). 

As a result of successful call deflection to an external number, the incoming call (external or internal) shall no longer be 
presented to any PP. 
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It is recommended that the deflected-to telephone number is pre-configured (in the handset) before using this service. 
The PP related procedures to pre-program and display the deflected-to number is out of the scope of this procedure. 

If a user sends a call deflection request, and the deflected-to telephone number is internal, the FP shall: 

• present the incoming call to the "deflected-to" PP only (designated by the number in the request); 

• release the call on all other PP(s) that received the incoming call. 

If a user sends a call deflection request, and the deflected-to telephone number is external, the FP shall relay the service 
request to the network: 

• if the service can be provided, the FP shall release the incoming call on all PPs that received the incoming call; 

• if the service cannot be provided, the FP shall send a negative acknowledgment as described in clause 7.4.3.4 
(call status of the incoming call 'CS call setup' re-sent, along with call status reason 'control code failed'). The 
FP shall proceed further with the incoming call. 

NOTE 2: There are various mechanisms for the FP to be aware that the service can not be provided by the network. 
For example by getting a negative answer from the network when invoking the service or by 
configuration of the line. However these mechanisms are out of the scope of the present document. 

On the FP side, only the first call deflection request shall be taken into account. Possible further requests concerning 
this call and coming from the same or other PPs shall be ignored. 
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PP 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for exte 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 

CC-ALERTING 



call deflection request 

CC-INFO 



« MULTI-KEYPAD, '1C 39 15'H -i- number 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 



nal calls' : 



if the incoming call 
^ is external 



if request accepted: 
■4 



CC-RELEASE 



call deflection activation 
to 'number' 




GC-RELEASE-COM 



if request rejected (example): 

CC-INFO 



If user 
picks-up 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value 

< id type/subtype = 'Call status', value = 

< id type/subtype = 'Call status reason', 

» 

CC-CONNECT 



'01 'H > 
S call setup> 
vlalue = 'control code failed'> 



Figure 31 : Call deflection invocation when the deflected-to party is external 
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PP1 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for exte 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 
» 

CC-ALERTING 



call deflection request 

CC-INFO 



« MULTI-KEYPAD, '1C 39 17'H + number 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



PP2 



nal calls' > 



if the incoming call 
is external 



if request accepted: 



CC-SETUP 



« CALLING PARTY NUMBER» (see note 5) 



if the incoming call 
is external 



« CALL-INFORMATION, 

< Id type = 'Line identifier' > 

< Id subtype = 'Line identifier for external i 

< Identifier value = u > 

< Id type = 'Line identifier' > 

< Id subtype = 'line type information'> 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' 

< Identifier value = '01 'H > 



Ci ills' 



CC-ALERTlNG 



CC-RELEASE 



CC-RELEASE-COM 



if request rejected (example): 

CC-INFO 



If user 
picks-up 



« CALL-INFORMATION, 



< id 

< id 

< id 



type/subtype : 
type/subtype : 
type/subtype : 



'Call identifier', value 
'Call status', value 
'Call status reason' 



= '01 'H > 

CS call setup> 

^alue = 'control code failed'> 



CC-CONNECT 



Figure 32: Call deflection invocation when the deflected-to party is internal 



NOTE 3: The Call Control message sequences in figures 31 and 32 should be understood as examples. The real 

sequences may also contain different Call Control messages or Call Control messages in another order or 
Call Control messages with other contents. 
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NOTE 4: «CALLING PARTY NUMBER» is the deflected (remote) party calling party number. It could also be 
sent in a {CC-INFO} message. 

7.4.5 Line identification 

7.4.5.1 Line identification general requirements 

Line identifiers are used to identify the line on which an external call (incoming or outgoing) is made. Furthermore it is 
used by the FP to inform the PP about the line type (i.e.: 'network delay type', 'second call type', etc.) of the selected line. 

When the "Multiple line" feature is also implemented, Une identifiers allow to enhance the handUng of parallel calls in 
the "Common parallel call procedures" feature. However, when the "Line identification" feature is implemented, line 
identifiers shall be sent even if there is only one line in the system. Furthermore, if there are several lines in the system 
(meaning that the "Multiple hne" feature is also implemented), the line identifiers shall be used also for PPs attached to 
only one Une. 

Typically, a FP would use line identifiers in the 0..n interval, where 'n+l' represents the number of lines it handles. 

NOTE: A FP can support up to 127 lines. 

For a first or parallel outgoing external call, the Une identifier selected by the PP shaU be sent to the FP (see 
clauses 7.4.5.2 and 7.4.3.5.1). However, if the PP wishes to use 'FP-managed line selection' (see clause 7.4.5.2.4), it 

shall send the special line id value 'None' instead (see clause 3. 1). In both cases ('PP line selection' or 'FP-managed line 
selection') the FP shall send back the line id it selected for the call to the PP. 

This line identifier sent back by the FP shall also include the line type information included in the line identifier of 
subtype 'Line type information', with at least the following flags: 

• 'network delay type', indicating whether the delay of the network (to which the selected line is attached to) is 
'significant' (e.g. VoIP based network) or 'low' (e.g. PSTN/ISDN based network); 

• 'second call type', indicating whether the selected line in an 'double call with in-band signalling' line or not. 

For a first or parallel incoming external call, the line identifier value and line type information of the call (with at least 
the same flags as above) shall be notified from FP to PP (see clauses 7.4.5.3 and 7.4.3.5.2). 

The present document only specifies a single mandatory line id notification per call (either from PP to FP or from FP to 
PP); However, in order to ease implementation, and although it is no longer mentioned elsewhere in the present 
document, both parties are allowed to send the line id again in messages following this notification. But, for the sake of 
interoperabiUty, the party receiving these redundant line id values should ignore them. 

7.4.5.2 Line identification for external outgoing calls 

7.4.5.2.1 General line identification requirements for external outgoing calls 

For outgoing calls, the "Line identification" feature enables a PP to select the line on which the call has to be placed. 
For each outgoing call, the PP shall either : 

• select a specific line to place the call; or 

• select line identifier 'None' to let the FP manage the line selection for this call. 

Both modes shall be available for the user on PP side. 

NOTE 1 : The intention is to avoid implementations where PP would send only "None" Une identifier in front of a 
FP supporting several lines. 

If the PP has selected a specific line, it shall not make a different selection in a subsequent message. The PP shall not 
select a line it is not attached to (in that case the FP shall disconnect the call). 

If the PP uses line identifier 'None', the FP shall select a line on behalf of the PP. Whether the line is selected by the PP 
or by the FP, the FP shall send back to the PP the line identifier for the selected Une where the caU will be placed 
together with the line type information (see clause 7.4.5.1). 
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This procedure applies to all external outgoing calls (first or parallel). In the case of a parallel call, it only applies if the 
feature entitled "Common multiple call procedures" is also implemented. In that case, relevant procedures are described 
there. 

Exception case: if the PP has selected a specific Une in order to place an emergency call, the FP may consider that it 
has received a 'None' line identifier and use FP managed line selection instead, to process the call further. This 
exception shall not be used for non-emergency calls. 

NOTE 2: This rule allows the FP to select a more appropriate line if the PP specified line is not suitable (e.g. busy, 
out of order, etc.) when an emergency number is dialled. 

The line identifier information shall be sent using one of the following methods: 

• For Part 3 PPs, included in a « CALL INFORMATION » information element sent in the {CC-SETUP} 
message or in a {CC-INFO} message. 

• For GAP PPs, Part 1 PPs, and possibly Part 3 PPs, included in a « MULTI-KEYPAD » information element 
sent either in the {CC-SETUP} message, or in a {CC-INFO} message. This method shall only be used if the 
Une identifier is in the interval 0..9. If this method is used, the line identifier information shall consist in the 
poimd key ("#") character ('23'H) followed by the line identifier digit, IA5-coded on a single octet. 

7.4.5.2.2 Line identification for a f/rsf external outgoing call using «CALL 

INFORMATION» 

This procedures applies to the Part 3 FP and to a Part 3 PP effectively sending a line identifier for a first external 
outgoing call. This procedure uses the «CALL-INFORMATION» information element. 

When using the present procedure, and as an addition to procedure "Outgoing call request" of GAP [12], clause 8.2, a 
« CALL INFORMATION » IE shall be used for conveying the line identifier information. This IE shall be sent: 

either included in the {CC-SETUP} message; or 

included in a subsequent {CC-INFO} message, together with the first called number digit at the latest. 

If not using the present procedure for a first outgoing call, a Part 3 PP shall use procedure "FP managed line selection 
for & first external outgoing call" of clause 1A.52A instead. 



Table 24: Values used within the {CC-SETUP} message 
when the « CALL-INFORMATION » method Is used for conveying the line Identifier Information 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


<ldentifier type> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 





Code for 'Line identifier for external 

calls' subtype 


<ldentifier value> 


All 


The line identifier value itself 



The FP shall confirm the line selection of the PP by sending back a «CALL INFORMATION» IE conveying the line 
identifier information with the line identifier value and the Une type information. This IE shall be sent: 

• for a 'non early { CC-CONNECT } ' implementation of the FP: 

either included in the { CC-SETUP- ACK} message, if sent, and if the line id value was sent in the 
{CC-SETUP}; 

included in the {CC-CALL-PROC} message, if sent, and sent early enough; or 

otherwise, included in a {CC-INFO} message sent before the {CC-CONNECT}. In that case, the 
{CC-INFO} message contains a call id but does not bear any call status. 

• for an 'early { CC-CONNECT } ' implementation of the FP: 

either included in the { CC-CONNECT } message; or 
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in a { CC-INFO } message f oUowing the { CC-CONNECT } . 

The FP shall not use this confirmation to change the line to be used. If the selected line cannot be used, the FP shall use 
procedure "Busy system or hne notification" of clause 7.4.8.3 in order to disconnect the call. 



Table 25: Values used within the {CC-SETUP_ACK}, {CC_CALL_PROC}, {CCJNFO} or 
{CC_CONNECT} message used for confirming the line selection of the PP 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


<ldentifier type> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 





Code for 'Line identifier for external 
calls' subtype 


<ldentifier value> 


All 


The line identifier value itself 


<ldentifier type> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 


5H 


Code for 'Line type information' 

subtype 


<ldentifier value> 


'OO'B 
'01 'B 
•10'B 
'11'B 


Regular line with low delay 
Regular line with significant delay 
DCIBS line with low delay 
DCIBS line with significant delay 



PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

» 



CC-SETUP-ACK 



Store call in call table and 
assign call id 



« CALL-INFORIVIATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < Kevoad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 



start outgoing call 
towards peer party 
on line 'u' 



Figure 33: Line identification in {CC-SETUP} 
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PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



Store call in call table and 
assign call id 



« CALL-INFORIVIATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 
» 

CC-INFO 



« MULTI-KEYPAD. < Kevoad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



start outgoing call 
towards peer party 
on line 'u' 



Figure 34: Line identification in {CC-INFO} 
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PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



Store call in call table and 
assign call id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < Kevoad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 

CC-CALL PROC 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 



start outgoing call 
towards peer party 
on line 'u' 



Figure 35: Line identification togetlier witli called number in {CC-INFO} 



NOTE: The Call Control message sequence in figures 33, 34 and 35 should be understood as an example. The 

real sequences may also contain different Call Control messages, Call Control messages in different order 
or Call Control messages with other contents. 



7.4.5.2.3 Backward compatible line identification for a /y>'sf external outgoing call using « 

MULTI-KEYPAD » IE 

This procedure applies to the FP and a GAP or Part 1 PP, and possibly to a Part 3 PP, and allows the PP to send a line 
identifier for a first external outgoing call in a backward compatible way (i.e. using the «MULTI-KEYPAD» IE). 

When using the present procedure, a « MULTI-KEYPAD » information element shall be used for conveying the line 
identifier information. This information element shall be included in a {CC-INFO} message, as described in procedure 
"Sending keypad information" of GAP [12], clause 8.10. 

Table 26 shall be considered. 

NOTE: In the latter case, the «MULT1-KEYPAD» information element used may contain (partial or complete) 
called party number information. 
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Table 26: Values used within the {CC-SETUP} or a {CC-INFO} message 
when the «I\/IULTI-KEYPAD» method is used for conveying the line identifier information 



Information 
element 


Field within the 
Information element 


Standard values within the 
field/Information element 


Normative action/comment 


«Multi-keypad» 


<Keypad info> 


23H 


Code for the pound key ('#') used for 
introducing the line identifier 


30H - 39H 


The line identifier itself 



pp 

attached to line u e 1..9 



FP 



CC-SETUP 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '23 3u'H > » 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Use of line u 
for calling 
'called number' 



Network 




Figure 36: Line identification for a first external outgoing call, 
using the « MULTI-KEYPAD » method 



7.4.5.2.4 FP managed line selection for a first external outgoing call 

7.4.5.2.4.1 FP managed line selection for a ftrsf external outgoing call from a Part 3 PP 

This procedures applies to the Part 3 FP and a Part 3 PP making a first external outgoing call. It allows the PP not to 
specify any line identifier for this new call. 

In that case, the Une selection is said to be "FP-managed". 

When using the present procedure, and as an addition to procedure "Outgoing call request" of GAP [12], clause 8.2, a 
« CALL INFORMATION » IE shall be used for conveying the special line id value 'None' (see clause 3.1). This 
value shall be sent instead of a regular line id, at any possible time and in any possible location for sending a regular 
line-id as described in clause 7.4.5.2.2, i.e.: 

included in the {CC-SETUP} message; or 

included in a subsequent {CC-INFO} message, together with the first called number digit at the latest. 
A FP implementing this procedure shall therefore always be prepared to possibly select a line on behalf of the PP. 

NOTE 1 : The PP can therefore allow its user not to select any line (either on a caU-by-call basis, or permanently by 

configuration). 

A PP attached to only one line (e.g. registered to a FP with only one line) may use the present procedure. 

If a Part 3 PP uses the special line identifier value 'None', in order to use "FP managed line selection", it shall not select 
a line in a subsequent message. 
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When receiving 'None', the FP shall select a line on behalf of the PP. The FP shall then notify the selected line identifier 
value and line type information to the PP. This notification shall be sent, as described on figures 37, 38, 39 and 40: 

• for a 'non early { CC-CONNECT } ' implementation of the FP: 

either included in the {CC-SETUP-ACK}message, if sent, and if the 'None' value was sent in the 

{CC-SETUP}; or 

included in the {CC-CALL-PROC} message, if sent, and sent early enough; 

otherwise, included in a { CC-INFO } message sent before the { CC-CONNECT } . In that case, the 
{CC-INFO} message contains a call id but does not bear any call status. 

• for an 'early { CC-CONNECT } ' implementation of the FP: 

either included in the { CC-CONNECT } message; or 

in a { CC-INFO } message following the { CC-CONNECT } . 

The FP may defer line selection and notification until it has all the information needed to make the selection (in 
particular, in some system configurations, the selected Une could depend on the dialled number). 



Table 27: Values used within the {CC-SETUP_ACK}, {CC_CALL_PROC}, {CCJNFO}. or 
{CC_CONNECT} message used for conveying the line identifier value and line type information 



Information element 


Field within the 
Information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


<ldentifier type> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 





Code for 'Line identifier for external 
calls' subtype 


<ldentifier value> 


All 


The line identifier value itself 


<ldentifi8r type> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 


5H 


Code for 'Line type information' 
subtype 


<ldentifi8r value> 


'OO'B 
'01 'B 
'10'B 
'11'B 


Regular line witfi low delay 
Regular line with significant delay 
DCIBS line with low delay 
DCIBS line with significant delay 



NOTE 2: Some kind of "FP managed line selection" may also be used for "Call intrusion" (see 7.4.3.8) and is used 
for "Headset management" (see clause 7.4.16.2.2). 
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PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 

» 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< identifier subtype = 'Line identifier for externai caiis' > 

< identifier value = u > 

< identifier type = 'Line identifier' > 

< identifier subtype = 'Line type information' > 

< identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 



Store call in call 
table and assign 
call id 



Selects u among 
lines attached to PP 



The FP sends the line id 

- also if the PP is attached to 
only one line 

- or if there is only one line in 
the system 



start outgoing call 
towards peer party 
on line 'u' 



Figure 37: FP-managed line selection in {CC-SETUP-ACK} (together with call id assignment) 



ETSI 



115 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 

CC-SETUP-ACK 



« CALL-INFORIVIATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« IVIULTI-KEYPAD. < Kevoad info = 'called number' > » 
« CALL-INFORIVIATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



CC-CALL-PROC 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 



Figure 38: FP-managed line selection deferred to {CC-CALL-PROC} 



Store call in call 
table and assign 
call id 



start outgoing call 
towards peer party 
on line 'u' 



Selects u among 
lines attacfied to PP 



The FP sends the line id 

- also if the PP is attached to 
only one line 

- or if there is only one line in 
the system 



NOTE 3: This can be used in case the line id selected by the FP would depend from the called number, the FP may 
wait until the called number is received (partly or completely) before it notifies the line id used. 
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PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < Kevoad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

CC-CALL-PROC 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 



Store call in call 
table and assign 
call id 



Selects u among 
lines attached to PP 



Notify PP of the 
chosen line-id and 
starts outgoing call 
towards peer party 
on line 'u' 



Figure 39: Deferred use of 'None', togetlier witli caiied number 
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PP 



« CALl -INFORMATION, 



< Ide 

< Ide 



CC-SETUP 



FP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 



CC-CONNECT 



Store call in call table 
and assign call id 



itifier type/subtype = 'Call identifier' > 
itifier value = '03'H > 

CC-INFO 



Early CC 



message used 



CS call c 



>nnect call status 



not yet re ached 



« CALl -INFORMATION, 

< Idei tifier type = 'Line identifier' > 

< Ider tifier subtype = 'Line identifier for external calls' > 

< Idei tifier value = u > 

< Ider tifier type = 'Line identifier' > 

< Idei tifier subtype = 'Line type information' > 

< Idei tifier value = 'xy'B > 

< Ider tifier type/subtype = 'Call identifier' > 

< Ider tifier value = '03'H > 

< Ider tifier type/subtype = 'Call status' > 

< Ider tifier value = 'CS call setup ack' > 



Figure 40: Example of use with an early {CC-CONNECT} implementation 



CONNECT 



7.4.5.2.4.2 



Backwards compatible FP managed line selection for a ftrsf external outgoing call 



This procedures applies to a Part 3 FP in front of a GAP or Part 1 PP making a first external outgoing call. 

For a given call, the default behavior of a GAP or Part 1 PP making a first external outgoing call is to send no line 
identifier. 

A Part 3 FP implementing this procedure shall wait for the first keypad information received from the GAP or Part 1 
PP. If the keypad information is different from '23'H ('#' character), it shall infer that FP managed line selection is used, 
and shall therefore select a line on behalf of the PP. 

NOTE: This corresponds to the classical way of using a GAP or Part 1 PP. 

The FP may notify back the user of the PP of the used line identifier using a «DISPLAY» information element. 
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GAP or Part 1 PP 

attached at least to 
line u 



FP 



Network 



CC-SETUP 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Selects u among 
lines attached to PP 



CC-INFO 



« DISPLAY, info = "Line u is used"> » 



Use of line u 
for calling 
'called number' 




Figure 41 : Backward compatible FP managed line selection 



7.4.5.3 



Line identification for external incoming call 



7.4.5.3.1 



General line identification requirements for external incoming calls 



For incoming calls, the "Line identification" feature enables the FP to notify the PP of the line on which the incoming 
call was received. 

NOTE: The current general procedure applies to all external incoming calls (first incoming call or waiting call). 
In the case of a waiting call, it applies conditionally to the implementation of the feature entitled 
"Common multiple call procedures". 

For incoming calls, the line identifier information (including the 'hue type information') shall always be sent included in 
a « CALL INFORMATION » information element, as follows: 

• For a first incoming call, it shall be sent in the {CC-SETUP} message, as decribed in clause 7.4.5.3.2. 

• For a waiting call, it shall be sent in every {CC-INFO} message used for notifying the waiting call, as decribed 
in clause 7.4.3.5.2. 

7.4.5.3.2 Line identification for a /y>'sf external incoming call 

For incoming calls, the "Line identification" feature enables the FP to notify the PP of the line identifier of the line on 
which the incoming call arrived. Furthermore it is used by the FP to inform the FP about the 'line type information' of 
the selected Une. 

A line identifier for an incoming call shall be sent from FP to PP in a «CALL INFORMATION» information element in 
the { CC-SETUP }message, as an addition to GAP [12], clause 8.12, "Incoming call request". 

The FP shall notify the hne identifier used even if there is only one hne in the system, and even if the PP is attached to 
only one hne. 
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PP 

attached at least to 
line u 



CC-SETUP 

4 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 



CC-ALERTING 
► 



Figure 42: Line identification for a first external incoming call 

7.4.6 Call identification 

7.4.6.1 Call identification general requirements 

The "Call identification" feature handles: 

• The definition of a call identifier (or call id) by the FP for each call, and the use of this call id in both 
directions to identify the call a received message belongs to. 

• The sending from FP to PP of a call status - at some points of the call progression- and in some cases of an 
associated call status reason (see clause 7.4.6.4). 

Call identifiers are used to identify all ongoing calls in a DECT system, internal or external. They allow to enhance the 
"Parallel call" and "Multiple call" features. More specifically: 

• Call identifiers allow to properly handle PPs with more than 2 call instances, especially for all double call 
related procedures (see clause 7.4.3.5). 

• Even for PPs with only 2 call instances, call identifiers allow to properly handle asynchronous messages (for 
example a call toggle from the PP crossing a call release from the FP). 

Call identifiers are assigned by the FP and are uniquely defined DECT system- wide. In other words, call identifiers 
shall NOT be PP specific (i.e. there shall never be two equal call identifiers, even for 2 different PPs), nor line specific. 



FP Network 

1 

/ Incoming call to line u 
from 'calling number' 
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■) line 1 
(external number 1) 

;)line2 
(external number 2) 



Figure 43: Calls identifiers are assigned by the FP and unique for the DECT System 

A call identifier is assigned each time a call is setup. In order to be usable for parallel/multiple calls, a call identiiier 
shall be assigned also for the first call of a PP. 

The call identifier is freed on PP side at call release ('CS idle' received from the FP, or {CC-RELEASE-COM} sent or 
received by the PP). The PP shall no longer use the call id value except on FP's initiative. 

The call identifier is freed on FP side (and available for a further new call): 

• at call release if the call only involves one PP ('CS idle' sent to the PP, or {CC-RELEASE-COM} sent or 
received by the FP); 

• if several PPs are involved in the call (e.g. in case of call transfer, multiple call line, headset call interception, 
etc.), when the call does no longer exist in the system, i.e. at the time the call is released for the last PP 
involved in the call. 

The FP call identifier assignment method is left free to implementation. However, it is recommended to avoid possible 
conflicts of assignment when a call is being released while an other one is being setup on the same PP (avoid re-using 
the first free call id). The FP may implement the "no re-use method" described below, which allows this. 

The "no re-use method" consists in assigning a call identifier to a new call in the interval [0, n]. Assignment starts or 
restarts at each time the system comes back to idle (all registered PPs are back to idle). For further calls, the rule 
"Assigned id = latest assigned id in time +1" applies. Latest assigned id may correspond to a still ongoing or an already 
terminated call. This method assumes that n is never reached. An easy implementation can be done by using n=127 (127 
is the maximum call identifier length if no extension for the call identifier value is used). 

The FP shall send a call identifier together with every call status sent to the PP, as specified in clause 7.4.6.4, and more 
generally, with all messages relating to the identified call (especially including the {CC-INFO} messages conveying the 
CLIP and the CNIP for a first incoming call -if a {CC-INFO} message is used- although there is no associated call 
status in this case). The first sending of the call identifier to the PP notifies the PP of the call id assignment for the call, 
as specified in clauses 7.4.6.2 (first outgoing call), 7.4.6.4.6 (first outgoing call using early CC-CONNECT 
implementation) and 7.4.6.3 (first incoming call), 7.4.3.5.1 (parallel outgoing call) and 7.4.3.5.2 (call waiting 
indication). 

The FP may notify the call id assignment while the call is being disconnected (i.e. together with call status 'CS call 
disconnecting'), as illustrated in clause 7.4.8.3, "Busy system or line notification". However, the FP shall not notify the 
call id assigrmient while releasing the call (i.e. together with call status 'CS idle'), as specified in clause 7.4.3.5.4, "Call 
release and call release rejection" 

The PP shall send call identifiers in {CC-INFO} messages as specified in clauses 7.4.6.4.5 (first outgoing call) and in 
7.4.3.5 (parallel calls), for all messages or requests relating to the identified call. As a result, once a call identifier is 
assigned, all the subsequent {CC-INFO} messages shall include a call identifier (i.e. Keypad, CLIP, CNIP, Signal, 
Display, etc.) 
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Call identifiers shall be sent within the «CALL-INFORMATION» information element with <Identifier type> and 
<Identifier subtype> fields both equal to 'Call identifier'. It shall be sent in case the sending party (PP or FP) implements 
the "Call identification" feature. The format to be used in all messages is shown in table 28. 



Table 28: Values used within any applicable CC message 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


<ldentifier type> 


1 


Code for 'Call identifier' identifier type 


<identifier subtype> 





Code for 'Call identifier' subtype 


<ldentifier value> 


All 


The call identifier value itself 



NOTE: The "Call transfer", "3-party conference with established internal and/or external calls" and "Call 

intrusion" features also make use of call identifiers with a different <Identifier subtype> = 'Updated call 
identifier', for the purpose of updating the identifier of an existing call. This subtype is not used within the 
"Call identification" feature itself. 

When implementing the feature, the PP shall set the corresponding terminal capability bit. 

Definition of 'early {CC-CONNECT} implementations'. It has been recognised that some existing implementations 
of GAP devices do not make use of the optional intermediate CC-States (e.g. Call Proceeding) for the first outgoing 
call, and rather send an early {CC-CONNECT}, thus using a simplified version of the state machine enough for the 
handling of PSTN calls in practice. In such implementations, the {CC-CONNECT} message from FP to PP is used as a 
way to require U-plane connection from the PP, even if the end to end connection with the remote party is not yet 
active. Such implementations avoid using the «PROGRESS INDICATOR» IE and minimise the number of 
exchanged CC messages. 

Such implementations, are allowed for Part 3 FPs, and are seamlessly integrated thanks to the 'Call status indication' 
procedure of clause 7.4.6.4 (see there for more details). 

Definition of 'Non early {CC-CONNECT} implementations'. This is used for implementation that are not 'early 
CC-CONNECT' ones. 

7.4.6.2 Call identifier assignment on first outgoing call (FP to PP) 

The purpose of this procedure is to have the FP assign a unique call identifier for a first outgoing call, external or 
internal, and notify it back to the calling PP. 

In case of internal call, the FP shall assign a single call identifier for both PPs. 

The assigned call identifier shall be notified back to the PP, by including a «CALL-INFORMATION» information 
element with <Call identifier> field value equal to the assigned call identifier in the first CC message sent back to the 
PP. More specifically, the call id assigned by the FP shall be sent first time to the PP as described below. 

• For "Non early { CC-CONNECT} implementations" (see clause 7.4.6.1), the newly assigned call id for a first 
outgoing call shall be communicated to the PP either: 

in a {CC-SETUP-ACK} if sent; 

in {CC-CALL-PROC} if sent, and if sent early enough; 
in a {CC-INFO} message sent FT to PT otherwise. 

• For "Early { CC-CONNECT} implementations" (see clause 7.4.6. 1), the newly assigned call id for a first 
outgoing call shall be communicated to the PP either: 

in the {CC-CONNECT} message itself, if sent early enough; 

in a { CC-INFO } sent FT to PT otherwise. 

NOTE: As described in clause 7.4.6.1, once the call id has been assigned and communicated to the PP, it is used 
in all subsequent messages (both directions) related to the same call. 
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• The outgoing call procedure of GAP (see clauses 8.1 to 8.6 of EN 300 444 [12]) shall be used with the 

following modifications: 

the Information element «Call information» with the content described in table 28 (see clause 7.4.6.1) 
shall be added to the content of the {CC-SETUP-ACK}, { CC-CALL-PROC } or {CC-CONNECT}, 
(depending on option) message with the rest of the content as described in EN 300 444 [12]; 

if the call identifier has not been sent in the {CC-SETUP-ACK}, { CC-CALL-PROC } or 
{CC-CONNECT} message, then a dedicated {CC-INFO} message, FT to PT, shall be added to the 
procedure carrying the Information element «CaU information» with the content described in table 28 
(see clause 7.4.6.1). 

PP FP 



CC-SETUP 








CC-SETUP-ACK 


Store call In call table 
and assign call Id 




> 


« CALL-INFORMATION, 

< Identifier type = 'Caii identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '03'H > 

CO-INFO 


» 

« MULTI-KEYPAD, < Keypad info = 'called number' 



NOTE: Only the call id assignment notification by the FP Is represented here. The call Id Is however present In the 
last {CC-INFO} message from PP to FP. 

Figure 44: Example of call identifier assignment on outgoing call, with call-id=3 

A call with basic service call class 'LiA service call setup' shall NOT be assigned any call identifier. See clause 7.4.10.6 
for more details. 



7.4.6.3 Call identifier assignment on first incoming call (FP to PP) 

The purpose of this procedure is to have the FP, upon a first incoming call, external or internal, assign a unique call 
identifier and send it to the PP. 

NOTE 1 : The "Handset locator" feature uses a kind of incoming call to which the FP also assigns a call identifier. 

In case of internal call, the FP shall assign a single call identifier for both PPs. 

A Call identifier for an incoming call shall be sent from FP to PP in a «CALL INFORMATION» information 
element in the { CC-SETUP }message. 

NOTE 2: The call identifier should not be displayed to the user. 

The procedure shall be performed as procedure "Incoming call request" from GAP (see clause 8.12 of 
EN 300 444 [12]), with the following modification: the information element «Ceill information» with the content 
described in table 28 (see clause 7.4.6.1) shall be added to the content of the {CC-SETUP} message described in 
table 22 of clause 8.12 of EN 300 444 [12]. 
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PP FP 





CC-SETUP 




< 

« CALL-INFORMATION, 


If the call is 
external 


< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information'> 

< Identifier value = 'xy'B > ^^^^^^^^^ 




< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call Identifier' > 

< identifier value = '02'H > 

» 



Figure 45: Example of Call identifier assignment on incoming call, with call-id = 2 



7.4.6.4 Call status indication to the handset (FP to PP) 
7.4.6.4.1 Call status indication general requirements 

The procedure "Call status indication to the handset (FP to PP)" provides the PP with timely and accurate information 
about the PP current call status (or calls statuses). Call statuses are used for outgoing and incoming calls, external and 
internal calls, first and parallel calls. 

The call status and call status reason information is primarily intended for displaying to the user accurate MMI 
information. (For instance a parallel call dedicated menu will only show up when the call is really connected with 
remote peer). 

More specifically, the aim of the present procedure is to: 

• enhance parallel call user experience for all Part 3 devices, by allowing the building of a state machine on PP 
side for every call (first and especially parallel calls); 

• increase accuracy of state information exchange for Part 3 FPs that will rely on an 'Early {CC-CONNECT}' 
implementation, while not breaking other implementations (see 'Early {CC-CONNECT}' implementations 
below for more information). 

The FP shall send the call status indication to the PP (see clause 7.4.6.4.3 for details). 

The PP may use this indication to inform the user of the status of the call (current procedure does not specify the way 
this information is displayed to the user. It could be a text string, an icon, etc.). 

For example, the PP may display to the user: 

• the communication duration; 



• context-dependent menus; 



• feedback to a user action (e.g. second call initiation, call toggle, call transfer request, conference call request, 
etc.); 

• information about another user action (the current call becomes a conference call, is being intruded, 
transferred, etc.). 

Information conveyed by call statuses. Information provided to the PP (and user) includes: 

• real network-side normal call status ("call proceeding", "ringing", "connected", etc.). In other words, the PP is 
provided with the status of the call towards the peer party (between FP and peer party); 
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• network-side call status in case of busy/error conditions; 

• call status reason. In addition to the indicated call status, the FP shall send the call status reason, if available 
in an error message from network or from the FP itself. 

Link with original CC state machine (handling of radio link and first call). The present procedure does not make any 
change to the original CC state machine, nor to CC state transitions (as triggered by CC messages). Especially, this state 
machine still contrains CC message ordering in both directions. U plane opening is still based on the «PROGRESS 
INDICATOR» IE or on the {CC-CONNECT} message. 

Rather, the present procedure adds a newly defined state machine (on PP side only) for each call including the first one, 
state transitions being triggered by the reception of call statuses (even for the first call). For 'Non-early 
{CC-CONNECT}' implementations, the sending of a call status for the first call generally coincides with the sending of 
the CC message of the same name. 

NOTE: Call status names are all prefixed with 'CS' for 'Call Status', in order to avoid any confusion with existing 
state transitions. For convenience, call statuses have names similar to the corresponding CC messages. 

Call status and external/internal calls. For external calls, call statuses originate from the FP or from the network. For 
internal calls, the call status always originates from the FP and is used with the same meaning. (In case of internal call, 
both implementations send the {CC-CONNECT} message at the same time). 

'Early {CC-CONNECT}' implementations, (see definition in clause 7.4.6.1). In such implementations, the CALL 

ACTIVE state-defined as reached when the { CC-CONNECT} message is sent-does no longer mean end to end active 
call. On the contrary, the 'CS call connect' call status shall always mean end to end active call (see however the PSTN 
special case in clause 7.4.6.4.3). 

Call statuses shall also be used for first calls, even in "Non early {CC-CONNECT} implementations", because the PP 

cannot guess which type of implementation the FP uses. For example, the PP shall always rely on 'CS call connect' for 
being informed of end to end activation of the call, and never on {CC-CONNECT} reception per se (which only means 
U-plane connection). 

EXAMPLES: Clauses 7.4.6.4.5 to 7.4.6.4.9 provide several examples explaining the use of the call status 
indication procedure. It has to be noted that the sequences are only examples, it cannot be 
mandatory that the message flows shall always be exactly in the described way. However it is 
recommended to follow the examples where possible in order to ensure interoperability. 

Backward compatibility. 

A Part 3 FP shall not send any call status to GAP or NG Part 1 devices. 

A Part 3 PP in front of a GAP FP or NG DECT Part 1 FP should behave as a GAP PP or NG DECT Part 1 PP 
respectively. 

7.4.6.4.2 Call status indication as call information 

The call status indication shall be sent in the «CALL INFORMATION» IE. 



Table 29: Values used within CC-messages 



Information element 


Field within the 
information element 


Standard values within the 
field/Information element 


Normative action/comment 


«Call-information» 


<ldentifier type> 


2 


Code for 'Call status' identifier type 


<ldentifier subtype> 


1 


Code for 'Call status' subtype 


<ldentifier value> 


All 


The 'Call status' value itself 


<ldentifier type> 


2 


Code for 'Call status' identifier type 


<ldentifier subtype> 


2 


Code for 'Call status reason' subtype 


<ldentifier value> 


All 


Tfie 'Call status reason' value itself 



Call identifier and call status 

Each time a call status is sent from FP to PP, the call identifier for the relating call shall be sent in the same «CALL 
INFORMATION» information element. 
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7.4.6.4.3 Call status principles and values 

General rules. The following three call statuses shall always be sent: 

• 'CS call setup' (for all incoming calls); 

• 'CS idle' (for all calls, incoming or outgoing, first or parallel). However, the use of the 'CS idle' call status for 
the last released call is optional (see clause 7.4.3.5.4); and 

• 'CS call connect' (for all incoming and outgoing calls, first or parallel, but only when the caU is end to end 
connected, and unless 'CS conference connect' is used). 

NOTE 1: Contrary to the 'CS call connect', the {CC-CONNECT} message indicates local U-plane connection and 
is sometimes sent before the call is end to end connected. 

The rules for using call statuses are further detailed in the 'Values summary and condition of use' clause below and 
especially in table 30. 

Other call statuses shall also be sent by the FP if applicable or upon reception of the corresponding information from the 
network. 

A {CC-INFO} message shall not be used to convey a call status for the first call before the {CC-CONNECT} has been 
sent. In this case, the standard CC message shall be used instead. 

Contrary to the case of first calls, the procedure "Call status indication to the handset" introduces the concept of a state 
machine on PP side for the handling of parallel calls. Consequently, call statuses for a parallel call are not conveyed 
within specific CC messages and shall always be sent using the all-purpose {CC-INFO {message type. 

Call statuses for a first outgoing call. Call statuses shall be used for a first outgoing call. The sending of a call status 
by the FP shall be as timely and accurate as possible with regard to the external world situation (network, other 
handsets). 

For a 'Non early {CC-CONNECT}' implementation of the FP, the sending of a call status for a first outgoing call shall 
coincide with the sending of the corresponding CC message: 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and shall be sent in 
{CC-SETUP-ACK}, {CC-CALL PROC}, {CC-ALERTING}respectively. The call status is used if and only if 
the corresponding message is used; 

• the call status 'CS call connect' shall always be used (if the call succeeds), and shall always be sent in the 
{CC-CONNECT} message. 

For an 'Early {CC-CONNECT}' implementation the sending of a call status for a first outgoing call shall be done by 
means of a {CC-INFO} message for call statuses sent after the {CC-CONNECT}. More specifically: 

• the {CC-CONNECT} message shall not bear any call status; 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and-for those which are 
used-shall be sent in this order in separate {CC-INFO {messages following the {CC-CONNECT} message; 

• the call status 'CS call connect' shall always be used (if the call succeeds) and shall be sent after the previously 
mentioned call statuses in a {CC-INFO} message following the {CC-CONNECT} message. 

Call statuses for a parallel outgoing call. Call statuses shall be used for a parallel outgoing call. More specifically: 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and - for those which are 
used-shall be sent in this order in separate {CC-INFO {messages, as part of the outgoing parallel call inititation 
(see clause 7.4.3.5.1); 

• the call status 'CS call connect' shall always be used (if the call succeeds) and shall be sent after the previously 
mentioned call statuses in a {CC-INFO} message. 

Call statuses for a first incoming call. Call statuses shall be used for a first incoming call. More specifically: 

• The call status 'CS call setup' shall always be used, and shall be sent within the incoming {CC-SETUP} 
message. 
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• The call status 'CS call connect' shall always be used, and shall be sent within a {CC-INFO} following the 
{CC-CONNECT-ACK} message. The {CC-CONNECT-ACK} message shall never be used to convey any 
call status. 

Call statuses for a parallel incoming call. Call statuses shall be used for a parallel incoming call. More specifically: 

• the call status 'CS call setup' shall always be used, and shall be sent in a {CC-INFO} message, as part of the 
call waiting indication (see clause 7.4.3.5.2); 

• the call status 'CS call connect' shall always be used, and shall be sent in a {CC-INFO}message if (and after) 
the call is accepted (see clause 7.4.3.5.6). 

NOTE 2: The sending of the 'CS call connect' call status by the FP for a first incoming call corresponds to the 

sending of the {CC-CONNECT-ACK} message, but is however sent in a separate {CC-INFO} message. 

Special case of PSTN calls. The use of call statuses for external calls on a PSTN Une is described in procedure 
'Handling of lines where second calls are signalled in-band' of clause 7.4.3.10. 

Values summary and condition of use. Table 30 explains use of the call status values defined in EN 300 175-5 [5], 
clause 7.7.56 "Call information". 



Table 30: Call status value explanation 



Call status 


Use 


Status 


Explanation 


CS call setup 


Incoming 
call 


Mandatory for incoming calls 


Incoming call presentation to local handset 
The handset has not yet confirmed user alerting 
(e.g. CS call alerting not yet sent) 


CS call setup ack 


Outgoing 
call 


If and only if the FP (or the 
network) is expecting to collect 
further dial information 




CS call proc 


Outgoing 
call 


If and only if the network 
provides corresponding 
signalling 


Call is proceeding. Dial information is assumed to be 
complete. The FP has started outgoing call towards 
the network (or internal party). No final response from 
network or internal party has been received yet 


CS call alerting 


Outgoing 
call 


If and only if the network 
provides corresponding 
signalling or for internal call 


Outgoing call is signalled (ring back) at called party 
side. A waiting call uses a control code for the same 
purpose in the opposite direction 


CS call connect 


Both 


Mandatory for all successful 
calls (unless CS conference 
connect is used) 


End to end call is active; voice is available 


CS call 
disconnecting 


Both 




Disconnect in progress, used from FP to differ the 
sending of 'CS idle' in order to signal in-band and/or 
Call status reason information to the handset 


CS call hold 


Both 


If and only if applicable 


connection is being held 


CS call under 
transfer 


Both 


If and only if applicable 


Used for unannounced call transfer in 

clause 7.4.3.6.2, to indicate that the incoming call is 

used for a call transfer 


CS conference 
connect 




If and only if applicable 


3PTY conference is active 

If used, replaces CS call connect 


CS call 
intercepted 




If and only if applicable 


Used in the "Headset management" feature (cf 
clause 7.4.16.2.2, Call interception) 


CS idle 


Both 


Mandatory for all calls except 
the last call; Optional for the 
last call 


Indicates that the corresponding call context must be 
deleted on PP side at least. For more detail, see 
clauses 7.4.3.5.4 and 7.4.6.1 



7.4.6.4.4 Call status reasons summary and MM! mapping 

The following table explains the use of the call status reason values defined in EN 300 175-5 [5], clause 7.7.56 'Call 
information'. 
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Table 31 : Call status reason value explanation 







system busy 


Call can not be proceeded due to general resource problems of tfie FP 


line in use 


Call can not be proceeded, because the choosen line (see clause 7.4.5.2 Line 
identification for external outgoing calls) is in use 


control code not supported 


Shall be sent by the FP in case the control code sent by the HS is not supported. 


control code failed 


Shall be sent by the FP in case execution of the control code sent by the HS was not 
possible or failed (for internal reasons or due to negative networl< response) 


user busy 


Called party is busy 


number not available 


Called number not available 



Table 32 gives some examples of which user interactions are possible when existing calls are in the indicated call 
statuses ('CS idle' being used also for not yet existing calls), especially for double call scenarios. 



Table 32: Mapping of call status (reason) to PP user interface actions 



Call statuses 


Reasonable display or control codes offered by the user 
Interface of the PP In relation to the Indicated call statuses 


Call Id 1 


Call Id 2 


CS call connect 


CS idle 


Initiating a second call external or internal / Call release / Putting a 
call on-hold 


CS call hold 


CS call setup ack / CS call 
proc / CS call alerting 


Call release / Call transfer request 


CS call hold 


CS call connect 


Call toggle request / 3-party conference call request / Call release / 
Call transfer request 


CS call connect 


CS call setup 


Call waiting acceptation / Call waiting rejection 


CS call hold 


CS idle 


Resuming a call put on-hold 


CS call disconnecting 
+ reason 'user busy' 


CS idle 


PP should present a "user busy"-display 



NOTE: Table 32 does not list aU possible call status combinations. 
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7.4.6.4.5 Call statuses for a first "Outgoing external call" 



PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



Store call In call table 
and assign call Id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

CC-INFO 



« MULTI-KEYPAD. < Kevoad Info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

» 

CC-CALL-PROC 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'OS call proc' > 

» 

CC-ALERTING 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call alerting' > 

» 

CC-CONNECT 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call connect' > 



start outgoing call 
towards peer party 



network message 'peer 
party Is alerting' 



network message 
'peer party Is active' 



Figure 46: Example of call status indication on outgoing call 

NOTE: For conciseness of the diagram, figure 46 does not show the exchange of line identifiers. 
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7.4.6.4.6 Call statuses for a first "Outgoing external call" 

using early {CC-CONNECT} message 



PP 



FP 



CC-SETUP 



CC-CONNECT 



Store call In call table 
and assign call Id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 



Early CC-CONNECT 
message used: 
CS call connect call status 
not yet reached 



CC-INFO 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'OS call setup ack' > 



CC-INFO 



« MULTI-KEYPAD. < Kevoad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 



» 



Identifier value = '03'H : 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'OS call proc' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'OS call alerting' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call Identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'OS call connect' > 



start outgoing call 
towards peer party 



networl< message 
'peer party is alerting' 



network message 
'peer party Is active' 



Figure 47: Example of call status indication on first outgoing call using early {CC-CONNECT} 

NOTE: For conciseness of the diagram, figure 47 does not show the exchange of line identifiers. 



ETSI 



130 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



7.4.6.4.7 



Call statuses for an "Outgoing external caH"-user busy 
PP FP 



Call established with 
call id = '03'H, and call status = 'CS call proc' 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call disconnecting' > 

< Identifier type = 'Call status' > 

< Identifier subtype = 'Call status reason' > 

< Identifier value = 'user busy' > 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS idle' > 

» 

CC-RELEASE 



CC-RELEASE-COM 



network message 
'user busy' 



timeout 



Figure 48: Example of call status indication on outgoing call, user busy 

NOTE: For conciseness of the diagram, figure 48 does not show the exchange of line identifiers. 
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7.4.6.4.8 



Call statuses for an "Outgoing external caH"-number not available 
PP FP 



Call established with 
call id = '03'H, and call status = 'CS call proc' 



CC-INFO 



« CALL-INFORIVIATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call disconnecting' > 

< Identifier type = 'Call status' > 

< Identifier subtype = 'Call status reason' > 

< Identifier value = 'number not available' > 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS idle' > 
» 



CC-RELEASE 



CC-RELEASE-COM 



network message 
'number not available' 



timeout 



Figure 49: Example of call status indication on outgoing call, number not available 

NOTE: For conciseness of the diagram, figure 49 does not show the exchange of line identifiers. 
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7.4.6.4.9 Call statuses for a first "Incoming external call" 



PP FP 







Incoming external 


CC-SETUP 


4 


call 


< 

« CALL-INFORMATION, 
< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 




» 




CC-ALERTING 




► 

CC-CONNECT 




► 

CC-CONNECT-ACK 
4 




CC-INFO 




4 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call connect' > 




» 





Figure 50: Call statuses for a first "Incoming external call" 
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7.4.7 Multiple lines handling 

7.4.7.1 Multiple lines common requirements 

The "Multiple lines" feature describes the behaviour of DECT systems connected to more than one network lines. A PP 
registered in such a DECT system may be attached to one or several of these lines. 

The "Multiple line" feature is only useful if the DECT system is connected to at least two different lines. 




Figure 51 : Example of a multiple line configuration with 3 lines (with attachments) 
PPs attached to several lines are hatched 



When implementing the "Multiple lines" feature, the PP shall set the corresponding terminal capability bit. The FP shall 
set bit of the "Extended higher layer capabilities (part 2)" (see EN 300 175-5 [5], clause F.3). 



7.4.7.1.1 Pre-requisites 

The following pre-requisites for implementation of the "Multiple lines" feature shall be taken into account: 

• A FP implementing the "Multiple lines" feature shall implement the "Line identification" feature as a 
pre-requisite. 

• A PP implementing the "Multiple lines" feature shall implement the "Line identification" feature as well. 

• A PP or FP implementing the "Multiple Unes" feature shall implement the feature entitled "Common parallel 
call procedures" of clause 7.4.3.5 as a pre-requisite, so that a new call on a different line can be placed or 
received on an already in use handset. 



7.4.7.1.2 Minimum requirements 

An implementation of the "Multiple lines" feature on a DECT system shall comply with the following minimum 
requirements: 

• The "Maximum number of simultaneous calls" supported by a FP implementing the "Multiple lines" feature 
shall be at least equal to 2. This includes support of as many simultaneous call contexts. 

• As the support the "Common parallel call procedures" of clause 7.4.3.5 (see clause 7.4.8.1.1) is a prerequisite, 
a PP implementing the "Multiple calls" feature shall support at least two simultaneous call contexts. 

NOTE: The last provision allows a multiple line PP attached to several lines to handle parallel call situations and 
can be seen as a consequence of the required support of the "Common pjirallel call procedures" of 
clause 7.4.3.5 (see clauses 7.4.7.1.1 and 7.4.7.2) 
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7A.7.2 Terminal attachment and line settings 

All registered PPs shall be attached to at least one hne. A multiple hne PP shall be prepared to be attached to at least 
two Unes. 

EXAMPLE 1 : A PP could be attached to a PSTN line and a VoIP line at the same time. 

More specifically, a multiple line PP shall provide a way for the user to select one of the available Unes. 

EXAMPLE 2: Line selection could be offered to the user through a menu, or by entering the keypad information 
#k, where k is the selected line number. 

The PP should consult the line settings list in order to offer only available line choices to the user (i.e. the list of lines 
the PP is attached to). 

7.4.7.2.1 Initial attachment 

The FP shall provide at least one of the following two possible attachment modes: 

FP-managed attachment: After subscription registration the PP is attached by the FP to one or several Unes with no 
specific user intervention. 

In case of FP-managed attachment, and in order to know the set of Unes it is attached to, the PP may read the "Attached 
handsets" setting of all "Line settings" list entries via the "List access service" feature [NG1.N.16]. 

PP-managed attachment: Default attachment is updated by the PP during or just after subscription registration. 

An initial PP-managed attachment shall be implemented as an update of the "Attached handsets" setting for every entry 
in the "Line settings" Ust corresponding to a targeted line, and performed via the "List access service" feature 
[NG1.N.16]. 

7.4.7.2.2 Attachment modification 

The PP should be able to change the initial attachment (add or remove Unes) during or after location registration. If 
supported, the PP shall initiate the procedure. 

An attachment modification shall be implemented as an update of the "Attached handsets" setting for every entry in the 
"Line settings" list corresponding to a targeted line, and performed via the "List access service" featme [NG1.N.16]. 

7.4.7.2.3 Line settings 

The FP shaU support the "List access service" feature [NG1.N.16] and the "Line settings" list. 

Apart from the "Attached handsets" setting itself, a PP shall only be able to update the settings of the lines it is attached 
to. 

7.4.7.3 Incoming and outgoing external calls on a multiple line system 

This procedure applies to the FP and to a PP attached to one or more Une(s), and to one of these Unes where a new call 
(incoming or outgoing) occurs (Une A in table 33). If the PP is idle, or already in communication on that line, no 
specific requirement is needed. Conversely, if the PP is already in communication on another Une (line B in table 33), 
specific requirements are needed. Table details the procedures to be used. 
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Table 33: Incoming and outgoing external calls on a multiple line system 





Incoming call on line A 


Outgoing call on line A 


All idle PPs 


Usual "mono-line" requirements apply 
(see notes 1 and 2) 


Usual "mono-line" requirements apply 
(see notes 1 and 2) 


All PPs attached to line A 
and in communication on line A 


All PPs attached to line A and B 
in communication on line B but not A 
(parallel incoming or outgoing call on 
another line A; see note 3) 


"Call waiting indication (external or 
internal)" (see clause 7.4.3.5.2), shall 
be used (see note 1 ) 


"Outgoing parallel call initiation" 
(see clause 7.4.3.5.1) shall be used 
(see note 1 ) 


NOTE 1 : In any case, "Line identification" must be used on PP and FP side. 

NOTE 2: The new call on line A may be a first call or a parallel call. If the line A is a multiple call line, please refer to 

clause 7.4.8.2, "Incoming and outgoing external calls on a multiple call line"; otherwise, usual procedures 

defined in the present DECT standard apply. 
NOTE 3: In this case, the PP is necessarily attached to several lines (at least A and B). The PP is busy with line B but not 

A, which means that with regards to line A it is not involved in any call. However, as it is not idle, parallel call 

procedures apply (feature "Common parallel call procedures" of clause 7.4.3.5). 



7.4.7.4 Internal calls in multiple line context 

This procedure applies to the FP and a PP attached to one or more line(s). 

Internal calls in multiple line context shall be possible between any two PPs, even if there is no line to which both PPs 
are attached. 

It should be possible to forbid internal calls between PPs that do not share a common line by configuration of the DECT 
system. 

7.4.7.5 Compatibility witfi non multiple line PP or FP 

This procedure applies to a non multiple line DECT equipement (PP or FP) in front of a NG-DECT Part 3 PP or FP 
implementing the "Multiple lines" feature. 

Non multiple line DECT equipment include: 

• NG DECT Part 3 FP, not implementing the "Multiple lines" feature; 

• NG DECT Part I PP or FP; 

• GAP PP or FP. 

NOTE: GAP and NG-DECT Part 1 PPs not implementing the "Multiple lines" feature do not necessarily mean 
that the PP is attached to only one line. It only means that the PP is not aware of possible multiple 
attachments. 

7.4.7.5.1 Non multiple line PP in front of a multiple line FP 

Attacliment: A non multiple line PP shall use FP-managed attachment and is not aware of the Unes it is attached to 
(only the user is). 

Outgoing calls: 

• A non multiple line NG-DECT Part 3 PP may use FP-managed line selection (see clause 7.4.5.2.4), and should 
however use the line identifier notification received to notify the user of the line used. 

• A non multiple line GAP, NG-DECT Part 1, or NG-DECT Part 3 PP may use the '#' key based line selection 
mechanism of clause 7.4.5.2.3 ("Backward compatible line identification for a first external outgoing call 
using «MULTI-KEYPAD» IE"). In that case, the user must manually enter the line identifier after the '#' 
key. 

Incoming calls: A non multiple line PP shall receive all incoming calls arriving on one of the lines it is attached to; a 
Part 3 PP should however use the line identifier received to notify the user of the line used. 
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7.4.7.5.2 Non multiple line FP in front of a multiple line PP 

In front of a "non multiple line" FP (hence connected to at most one line), a PP implementing the "Multiple lines" 
feature is however attached to a single line: 

• In front of a Part 3 FP, it shall however send the corresponding line id for each call, as specified in 
clause 7.4.5.2.2 (or alternatively clause 7.4.5.2.3), or use "FP-managed line selection", as specified in 
clause 7.4.5.2.4.1 (sending 'None' value instead). 

• In front of a GAP or Part 1 FP, it shall not send any Une identifier. 



7.4.8 Multiple call line handling 
7.4.8.1 Multiple calls general requirements 

The "Multiple calls" feature represents the ability for a FP and PP to support several fully parallel calls (outgoing or 
incoming) to and from a single line supporting the "Multiple call" mode. 




Figure 52: A multiple-call line with three simultaneous calls 



This feature is especially useful when several calls are placed or received on different handsets at the same time. 
However, a multiple call enabled DECT system is compatible and can be cormected to a non multiple call line like a 
PSTN line. 

From the DECT system point of view, a multiple call line may be configured in "single call" mode. To configure a 
multiple call Une in "single call" mode, or the other way round, the "Multiple call mode" setting of the "DECT system 
settings list" (see clause 7.4.11.4.8) shall be used through the "List access service" feature [NG1.N.16]. 

NOTE 1 : PSTN double calls are also a kind of multiple calls on a single hne, but always with a single handset for 
both calls, and only one call context active at a time. 

NOTE 2: "Multiple calls" is most notably a feature brought by VoIP protocols, allowing several call contexts to be 
opened simultaneously on network side. 



7.4.8.1.1 Pre-requisites 

The following pre-requisites for implementation of the "Multiple calls" feature shall be taken into account: 

• A PP or FP implementing the "Multiple calls" feature shall implement the "Call identification" feature as a 
pre-requisite. 
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• A PP or FP implementing the "Multiple calls" feature shall implement the feature entitled "Common parallel 
call procedures" of clause 7.4.3.5 as a pre-requisite, so that a new call can be placed or received on an already 
in communication PP. 

NOTE: On FP side, implementation of the feature entitled "Common parallel call procedures" also implies 
implementation of the "Line identification" feature. 

7.4.8.1.2 Minimum requirements 

An implementation of the "Multiple calls" feature on a DECT system shall comply with the following minimum 
requirements: 

• The "maximum number of simultaneous calls" supported by a FP implementing the "Multiple calls" featiu"e 
shall be at least equal to 2. This includes support of as many simultaneous call contexts. 

• The FP shall be able to support this maximum number of incoming or outgoing calls for idle PPs as defined in 
clause 7.4.6.2. This includes simultaneous ringing of all idle PPs on incoming calls and availability of all idle 
handsets for placing a new call when there is already a call going on on the line. 

• As the support the "Common parallel call procedures" of clause 7.4.3.5 (see clause 7.4.8.1.1) is a prerequisite, 
a PP implementing the "Multiple calls" feature shall support at least two simultaneous call contexts. 

7.4.8.2 Incoming and outgoing external calls on a multiple call line 

This procedure applies to the FP and the PP at external call (incoming or outgoing) setup on a multiple call line. This 
line naight be set in "multiple call" or "single call" mode. 

7.4.8.2.1 Line set in "single call" mode 

On a multiple call line configured in "single call" mode, only one call can be active at a time on the line. Other calls 
(second, or further) are on-hold and can only become active by replacing the existing one on the same PP. 

To handle a line in "single call" mode, the DECT system shall use the usual procedures defined in the present 
document. In particular, the feature entitled "Common parallel call procedures" shall be used to handle the second or 
further call on the same PP. 

If the line is busy, but implicit call intrusion is enabled by configuration, clause 7.4.3.8.1 shall be used instead of the 
"Busy system or line notification" procedure (see clause 7.4.8.3). 

7.4.8.2.2 Line set in "multiple call" mode 

On a multiple call line configured in "multiple call" mode, several calls may be active simultaneously; second and 
further calls are presented to all PPs (idle or busy) attached to the Une. Table 34 details the procedures to be used. 
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Table 34: Line set in "multiple call" mode 





incoming call setup 


Outgoing call setup 


On all idle PPs 
attached to the line 


GAP 8.12 "Incoming call request" shall be used 
(see note 1 ) 


GAP 8.2 "Outgoing call request" shall be used 
(see note 2) 


On all busy PPs 
attached to the line 


"Call waiting indication" (see clause 7.4.3.5.2), 
shall be used (see notes 3, 4 and 5) 


"Outgoing parallel call initiation" (see 
clause 7.4.3.5.1) shall be used (see notes 2 
and 3) 


NOTE 1 : Unless the DECT system is busy (see clause 7.4.8.3), although the line was not, in which case the call is 
not presented. 

NOTE 2: If the DECT system is busy, the "Busy system or line notification" procedure (see clause 7.4.8.3) must be 
used back. 

NOTE 3: All "Common parallel calls procedures", then, apply for handling the parallel calls. The fully parallel calls 

are in this case only alternatively active as for PSTN double calls. 
NOTE 4: On a multiple call line with VoIP interface, a call waiting procedure for already in use handsets may be 

used in the following two cases: a second VoIP call is received, or an in-band call waiting tone from a 

PSTN to VoIP gateway is received. However, the used procedures are the same. 
NOTE 5: If the call is meanwhile accepted by another PP, or if the remote party hangs up before the call is accepted 

by any PP, the call must be then released by the FP towards the current PP (see clauses 7.4.3.5.4). 



7.4.8.3 Busy system or line notification 

This procedure applies to the FP and a PP that initiated an outgoing call (external or internal) at a point in time where 
the FP and/or the line cannot support the additional call. The new outgoing call may be a first call, or a parallel call. 

NOTE 1: The current procedure applies within an outgoing call setup attempt. For idle PPs, a «DISPLAY» 

notification can also be used outside of any call for preventing call setup attempts, especially on a Une in 
single-call mode. 

NOTE 2: In single call mode, the line is considered busy for idle PPs, as soon as one call is going on on it. 

Busy line: A busy line is a line for which no new incoming or outgoing call can be performed, because all of the 
available bandwidth is used. This concept is especially relevant for multiple call Unes. 

Busy system: A DECT system is busy if the FP is not able to support any additional call, because the maximum 
number of call contexts it can handle has been reached. The system may be busy without the Une being busy. 

NOTE 3: A call context could be used by an internal call. A system should allow as many calls (external or 
internal) as there are call contexts potentially available on the system. 

On call setup attempt (first or parallel), if the system is busy or the line is busy, the FP shall send back a "busy system 
or hne notification" back to the PP, in the form of a «CALL_lNFORMATION> IE containing: 

• the call status 'CS call disconnecting' and the appropriate call status reason, (e.g. 'line in use' or 'system busy'). 

• the call identifier assigned for the call. This may be the first time it is communicated to the PP. 

NOTE 4: On the contrary, 'CS idle' cannot be sent with a newly assigned call id. 

Whenever required by the "Tones provision" feature, the FP shall additionally send a «SIGNAL» information 
element with <Signal value> field equal to 04H ('busy tone') included in a CC-INFO message. 

If the PP does not hook on after a time-out has elapsed, the FP shall send a call release request to the PP to terminate the 
call attempt. This call release request shall take the form of a CC-RELEASE message for a first call, or of a 
{CC-INFO} message according to procedure "Call release and call release rejection" (see clause 7.4.3.5.4), for a 
parallel call. 
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PP 

attached to 
a multiple-call line 



FP 
I 

the FP and/or the multiple call 
line cannot support the 
additional call: 



CC-INFO 



If required by the Tones provision' feature « SIGNAL, < value = 'busy tone' = 04'H > » 

« CALL-INFORIVIATION, 

< id type/subtype = 'Call identifier' value = '03'H > 

< id type/subtype = 'Call status' value = 'CS call disconnecting' > 

< id type = 'Call status' id subtype = 'Call status reason' value = 'line in use' > 

» 



CC-INFO 



After some 
time out 



« SIGNAL, <value = Tones off = '3F'H > » 

« CALL-INFORIVIATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

CC-RELEASE 



CC-RELEASE-COM 



Figure 53: Busy system or line notification for cail witfi defined cail-id=3 



7.4.9 PP and FP capabilities indication and broadcast 
7.4.9.1 Terminal capability indication 

NOTE 1: This procedure description replaces clause 8.17 of EN 300 444 (GAP) [12]. 

The PP shall be able to send the «Terminal capability» information element and the FP shall be able to receive it at 
least in {ACCESS-RIGHTS-REQUEST} and when location registration is supported in the {LOCATE-REQUEST}. 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 



Table 35: Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 


<Display capability> 


All 


If FT supports feature (GAP.N.24) it 
shall indicate in this field value which 
is equal to or higher than 2 


<Tone capability> 


All 




Echo parameters 


3 


VoIP compatible TCLw. See note 1 


Ambient noise Rejection 
(N-REJ) 


[1,2] 


See note 2 


Adaptive volume control 

(A-VOL) 


[1,2,3] 


See note 2 


Slot type capability 


All 


Full and long 640 slots mandatory; 
double and long 672 optional. See 
also note 2 


<Profile indicator 1> 


"xxxxxl x"B 


GAP and/or PAP supported 


<Profile indicator 6> 


"x1xxxxx"B, "xOxxxxx"B 


Fast or slow hopping radio 
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Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 




<Profile indicator_6> 


"1xxxxxx"B, "Oxxxxxx"B 


Support (or not support) of 
"no-emision" mode (optional MAC 
service [NG1.M.5]) 


<Profile indicator_7> 


"xxxxl 1 x"B 


New Generation DECT part 1 
(wideband speech) and part 3, 
(extended wideband speech services) 

supported 




"xxxl xxx"B or "xxxOxxx"B 


Support (or not support) of the 
"Headset management" feature 
[NG1.N.21] 




"xx1xxxx"B or "xxOxxxx"B 


Support (or not support) of the 
Re-keying and default cipher key 
mechanism early encryption' (related 
to feature [GAP. N. 35]) 








<Control codes> 


All 


If FT supports feature (GAP.N.25) it 
shall indicate in this field value which 
is equal to or higher than 2 


NOTE 1 : PPs compliant with the present document shall always set the value 3 ('1 1 'B) as result of the audio type 
requirements (see clause 6.8 table 7). FPs shall also understand the values 1 ('01 'B) and 2 ('10'B) that 
may be set by PPs compliant with NG-DECT Part 1 [21 ] or GAP [1 2] when attached to FPs compliant to 
the present document. 

NOTE 2: This capability is assumed as the default value (see table 36) if the «TERMINAL-CAPABILITY» 
information element is omitted. 



The capabilities in table 36 shall be assumed as default if the following fields in the «a'ERMINAL CAPABILITY» 
information element are not present. 



Table 36: Values assumed as terminal capabilities 



information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal capability» 


<Echo parameters> 


3 


VoIP compatible TCLw (see note 
1) 


<N-REJ> 


1 


No noise rejection 


<A-VOL> 


1 


No PP adaptive volume control 


<Slot type capability> 


"xxxl x1 x"B 


Full slot and Long slot (]=640) 
supported (see note 2) 


NOTE 1 : Value 3 (VoIP compatible TCLw) shall be assumed if the PP has declared to be a NG-DECT Part 3 PP. For 
GAP and NG-DECT Part 1 PPs the default values given in [12] and [21] shall be assumed. 

NOTE 2: This value shall be assumed if the PP has declared to be a NG-DECT Part 3 or part 1 PP. For GAP PPs 
the default values given in [12] shall be assumed. 



No echoing of characters is allowed in the FT and therefore the PT would be responsible for displaying dialled digits. 
All display information from the FT would be assumed to be additional information that the F*T shall display in 
addition. The PT shall logically separate display information originating at the FT and PT. This could be achieved, for 
example, by one physical display and two logical displays or two physical displays and two logical displays. The key 
point is that display characters from the PT and FT shall not be simultaneously interleaved/mixed on the same physical 
display. 

7.4.9.2 Higher layer information FP broadcast 

The FP and PT shall support the broadcast of Higher Layer capabilities as part of Qt MAC broadcast messages (see 
clauses 7.6.3, 7.6.4 and 7.6.5). 

The broadcast attributes are a small set of NWK layer and DLC layer capabilities (jointly known as "higher layer 
capabilities") that shall be broadcast regularly as part of the MAC layer broadcast service. See EN 300 175-5 [5], 
annex F. 

RFPs belonging to the same LA shall broadcast the same values of higher layer attributes (see EN 300 175-5 [5], 
annex F) at any given time. 
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The PP shall be capable to read and interpret at least the following broadcast attributes codings during locking 
procedure. In the locked state the PP may assume them as static. 

FP and PT shall support the following values of "Higher Layer capabilities" information attributes. 

7.4.9.2.1 Higher layer information in standard FP broadcast (Qli= 3) 

The requirements of clause 7.3.9.1 of TS 102 527-1 [21] shall apply. 

7.4.9.2.2 Extended Higlier Layer capabilities part 2 

The Extended Higher Layer capabiUties, part 2, Fixed Part Information field shall be used indicating the supported set 
of Wideband speech Services. 



Table 37: Extended Higher Layer Capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


< > 


NG-DECT Wideband voice 
supported 


1 


See TS 102 527-1 [21] (see note) 


<a29> 


NG-DECT extended 
widewband voice services 
supported 


1 


The present document (see note) 


<a30> 


Permanent CLIR 


[0, 1] 


Related procedures: clause 7.4.12 


031 > 


Third party conference call 
(external or external) 


[0, 1] 


Related procedures: clause 7.4.3.7 


<a32> 


Intrusion call 


[0,1] 


Related procedures: clause 7.4.3.8 


<a33> 


Call deflection 


[0,1] 


Related procedures: clause 7.4.4.1 .1 , 7.4.4.2 


<a34> 


Multiple lines 


[0, 1] 


Related procedures: clause 7.4.7 


<a35> 


"no emission" mode support 


[0,1] 


Related procedures: see NG1.M.5 in clause 6.12 


< a42 > 


Support of 'Re-keying' and 
'early encryption' 


[0,1] 


Support (or not support) of the 'Re-keying' and 
'default cipher key mechanism early encryption' 
procedures (related fo feature [GAP.N.35]) 


NOTE: Value refers to the value to be set by FPs complying with the present document. PPs may need to 
understand other values due to the compatibility with GAP and NG-DECT Part 1 FPs. 



Even if a capability bit relates to a feature which is mandatory in the present document, this bit shall be set (indicating 
the support of the feature). Setting only the bit a29 NG-DECT "extended wideband voice services supported" is not 
sufficient. 

7.4. 1 List access service 
7.4.10.1 General considerations 

Equipment supporting New Generation DECT Part 3 shall support the "List access service" feature as described in the 
present clause. The lists managed by this feature are structured as represented in figure 54. 
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. name 
. first name 
. contact 
number 
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n entries 
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interception 



n entries 



User data oriented lists 



etc. 



DECT system 

settings list 



. FP registra- 
tion mode 
. PIN code 
. clock master 
. Base reset 
. FP IP 
address 
. FP version 
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. Line id 
. Line name 
. attached PP 
. dialling prefix 
. FP melody 
. FP volume 
. blocked nb 
. multiple calls 



m entries (1 entry per line) 
► 



DECT system and line settings lists 



list access 

Figure 54: Structure of the lists managed by the "List access service" feature 

The list access feature defines a generic way to access lists located in the FP from the PP. This access includes 'read', 
'edit' and 'delete' functionalities. 

The procedure is based on IWU-Info messages, which contain the information element «IWU to IWU», using the 
dedicated protocol discriminator '03 'H. 

Table 38: Values used within the «IWU to IWU» information element 



Information element 


Field within the Information 
element 


Standard values 
within the fleld/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 


<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command > 


1...127 


List access command (see note) 


<Command specific byte 0> 












<Command specific byte L-2> 






NOTE: Values from 128 on are reserved for proprietary list access commands. 



The S/R bit shall always be set to '1'. Use of value '0',"Rejection of message", as described in EN 300 175-5 [5], 
clause 7.7.23, is not forseen in the present document as dedicated commands/codes exist to handle list access error 
cases. 

Access to a list is encapsulated in a session. Each session is linked to exactly one list access and is used: 

• by the FP to grant access to a list; 

• to handle accesses to multiple Usts from one PP. 

Typical sequences of commands between start and end of a session are the following: 

• "Read entries" or "search entries", for just reading entries. 

• "Read entries" or "Search entries" followed by "Edit entry" and "Save entry" for updating an existing entry, if 
an "Edit entry" has been issued but the list entry is left unchanged, a "Save entry" command shall still be used 
to unlock the entry. 

• "Save entry" with entry id equal to 0, for creating a new entry in the Ust. 

Entry identifier: Each entry in a list is unambiguously identified within the FP for a dedicated list by an entry id. This 
entry id has to be referenced in case of writing access and is also used by the FP to reject multiple write accesses from 
several PPs. 
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Field identifier: Each entry of a list may contain several fields. Each field has a unique identifier which is list 
dependent (see clause 7.4.10.5). This means the same field may be included in several list but with a different field id. 
This shall be taken into consideration when using field id in a command. 

List index: The list index determines the position of an entry in a sorted list and is used for navigation within a list. The 
list index may change after modification of the list. 

In order to indicate list changes to the PPs, a notification procedure is defined. This enables the PP to read list contents 
in advance before using them (caching), enabUng the PP both to hold local copies of Usts and to anticipate operations 
around the current entry, in order to save time and so increase interactivity (faster MMIs on PP side). 

Bytes order: When characters are transported in the «1WU to IWU» information element, the most significant byte 
shall be sent first. For example, character with code point U+00A2 is coded in UTF-8 as 'C2'H 'A2'H and conveyed 
with 'C2'H as the most significant byte. 

Guarantee of service: 

When the FP supports a list, it shall manage and process all mandatory commands. See table 41 in clause 7.4.10.4 for 
details. Negative answers are allowed only for real faulty cases and shall not be used systematically. Especially, the FP 
shall not declare it supports a list and respond with negative answers to all commands. 

When a PP supports a list, the PP shall provide to the user all mandatory commands decribed in table 40 of 
clause 7.4.10.4. 

When the FP supports a Ust, the FP shall implement all fields of this list as defined in clause 7.4.10.5. For DECT system 
settings list and line settings list, the status of the fields are given in table 9 (see clause 6.10). The FP shall have the 
capability to store and retrieve these fields to the PP. The defined structure of list entries describes the way they are 
exchanged over the air, and it does not necessarily mean this is the way they are actually stored in the FP memory. For 
example, the line name does not need to be stored for each entry in the FP (because it can be retrieved from the Une id), 
although it has to be present in each entry if the field exists for the list and is requested by the PP. 

Each field has to be in each list entry at least once (a field may also be included more than once in each entry of the 
list). All entries of a list shall include the same fields. The PP may read, edit and save only some of the fields of entries 
of these lists (see each command in clause 7.4.10.4 for details). 

EXAMPLE 1: A PP may request the fields of an entry in two steps. In a first step, the PP only requests a subset of 
the fields (but for several entries) to allow the user to browse the list. In a second step, when the 
user actually selects one of the entries, the PP requests all the fields, but for the selected entry only. 

EXAMPLE 2: A PP may not request the linename field, as soon as it is able to display it: the PP could retrieve 

this field from the line settings list thanks to the line id (changes to the line settings list are notified 
to the PP, see clause 7.4.10.2.2). 

The FP always remains the master of the entry fields that are available in a list (number of fields per entry remains 
always the same and statically defined by FP). These fields can not be removed nor added from the list by any PP (they 
can only be eventually reset by the PP). This is also valid when a field is included more than once in all entries. 

When the FP supports a field of an entry, it shall support as many values as possible for the field and process this field 
correctly. For example: if the FP uses a name entry field it shall fill it correctly and not always leave it empty. 

When the NG-DECT Part 3 system supports a list, it shall also implement the corresponding service related to this list, 
entry or field. The PP shall display as many fields as possible. For example: if a FP declares a contact list, the FP shall 
fill it correctly and support all mandatory requests fiom all PPs. The PP shall provide access to this contact to the user 
and not re-create a local copy of the list. 

Of course the FP shall update automatically missed calls, outgoing call, all call list by adding locally corresponding 
entries in the lists. 

Display and edition of string fields: 

Both the PP and FP shall work in best effort mode. Meaning: do their best with their display capability, edit and storage 
capacities on each side independently. 

If PP saves or edits a longer string than the FP is able to store, the FP shall store only the first characters of the saved 
string (the FP shall truncate it). 
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The PP will be aware of the truncation only when reading/editing the string a second time. 
If the PP edits a string that is longer than its display capabiUty: 

• The PP may display to the user, edit and save the complete string by scrolling (recommended behavior). 

• The PP may display, edit and save only the first characters, compatible with its display capability (fall back 
mechanism to be used if reconmiended behavior is not implemented). 

Alphabet compatibility: 

List entry fields with characters shall in the FP be stored in UTF-8 format. 

PP shall support at least IA5 characters, and shall understand UTF-8 encoding format. 

PP should not modify UTF-8 characters that it does not support, unless the character is edited by the user (e.g. replaced 
with a character supported by the PP). 

Additionally, the PP should follow the guidelines given in clause 7.4.17.2 ("display of UTF-8 characters on PP side") 
for the display of UTF-8 encoded characters. 

Initial values: 

• First possible session identifier assigned by FP shall be "1". Value "0" is a reserved return value used by the 
FP when a problem occurs. 

• First possible "list identifier" shall be "0" (see clause 7.4.10.3 for Ust identifier coding). 

• First possible " entry identifier" assigned by FP shall be " 1" . 

• First possible "field identifier" shall be "1". 

• First possible "Start index" parameter value in read entries confirm/search entries confirm commands shall be 
"1". Start index may be equal to in read entries command to point on the last entry. 

• First possible "position index" parameter value in save confirm command shall be "1" (first entry). 
Sessions: 

FP side: The number of simultaneous sessions is left free to FP implementation. However, the FP shall fulffill the 
following minimum requirements: 

• The FP shall be able to handle 2 started sessions initiated from a single PP at the same time on two different 
hsts. 

• Once the maximum number of sessions is reached in the FP (for different Usts or the same list) the FP shall 
issue a dedicated error code for any further start sessions attempts (in the start confirm see clause 7.4.10.4.1.2). 

NOTE 1 : A simple FP implementation could be to support only 1 started session at a time for a given list (to avoid 
potential collision scenarii). An other dedicated start session confirm error code exists for this. However, 
the list access protocol fully allows to support multiple sessions started over the same list. 

PP side: The number of simultaneous sessions is left free to PP implementation. 

NOTE 2: However it is recommended that the PP allows to save a number from a call list into the contact list. 

Depending on the PP implementation, support of 2 simultaneous sessions could be convenient for this. 

All sessions between a PP and FP are ended at the latest at call release. 

The number of entries allowed within a list is defined by the FP (manufacturer dependent). A dedicated error code shall 
be used if PP tries to save new entry in a full Ust. 

Handling of collision scenarii when a FP allows several PPs to access the same list simultaneously : 

• It is recommended that the second start session uses the same sorting criterion as the first start session. 
(However, FP will decide the final sorting criteria in start confirm and will probably re-use the same sorting 
criteria as the first started session). 
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• The FP shall send hst change notifications upon changes in this list (see clause 7.4.10.2). 

• No collision occur while both PPs perform only read entries / search entries commands. 

• One PP may be marginally un-synchronised concerning the content of one entry if the other PP modifies this 
entry (with edit+save). However, PP will be re-synchronised at its next read entries /edit entry/search entries 
command. 

• One PP may be temporarily un-synchronised from the list if the other PP deletes, creates (with save) an entry 
or deletes the list (cases where the total number of entries or position index of some entries are modified). 
Existing error codes for later "edit entries", "read entries" / "search entries" prevents potential problems. PP 
will be fully re-synchronised only when performing the next start session command, (see clause 7.4.10.2 for 
details). 

• Edit entry command prevents severe collisions by locking an entry (relying on entry id and not position index). 

7.4. 1 0.2 List change notification 
7.4.10.2.1 General rule 

The present 'List change notification' procedure describes the use of the 'list change indication' type of generic events 
notification (see clause 7.7.55 of EN 300 175-5 [5J). It is potentially usable with any of the lists described in 
clause 7.4.10.5, but: 

• Clause 7.4.10.2.2 enumerates the lists for which the present procedure makes a 'list change indication' 
mandatory. Use of the procedure for other lists is optional and may not be relevant. 

• The 'missed call list' does not use the list change notification procedure (see clause 7.4.10.2) for the sending of 
hst change indications. The procedure 7.4.1.3 'Missed call notification' describes all uses of a 'hst change 
indication' for the 'missed call hst'. 

Line identification used in a 'list change indication'. As a general rule: 

• If the hst contains a line identifier field, a 'line change indication' shall contain a line identifier, specified in a 
«CALL INFORMATION» IE. The line id to be used is described below (see 'Events triggering the 
notification' clause) 

• If the list does not contain any line identifier, the list change indication shall NOT contain any 
«CALL-INFORMATION» IE. 

Event multiplicity. The <event multiplicity> field shall contain the total number of entries in the hst /or the specified 
line id at the time the notification is sent. More specifically: 

• If the specified hne id subtype 'Line identifier for external call' or 'Relating to' is used, the entries with 'All 
lines' value shall not be counted. 

• If the specified line id subtype is 'All lines', only entries with this subtype shall be counted. 

NOTE 1 : As a result, if one entry of the Line settings list is modified, a hst change notification is sent with the 
event multipUcity value set to 1, together witii a «CALL INFORMATION» IE set to 'Relating to' 
subtype and the line identifier value (see also clause 7.4.10.2.2). 

Events triggering the notification. When the present 'List change notification' procedure is implemented by the FP for 
a list, the following event types shall trigger a 'list change indication' from the FP. For each event type, the hne to 
specify and the set of PPs receiving the notification (targeted PP or PPs) are indicated. 

• Entry created, modified, or deleted. If an entry in the list is created, modified or deleted, a 'list change 
indication' shall be sent. 

Specified line (only if the list contains a line identifier field): The line id subtype used, and the value used 
(if any value) shall be those of the concerned entry. 

NOTE 2: If the hne id subtype 'All hnes' is used, the line id value field is absent. 
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Targeted PPs: All PPs attached to the specified hne: 

■ If the concerned entry relates to a single line (line id subtype 'Line identifier for external call' or 
'Relating to'), the notification shall be sent to all PPs attached to the corresponding line. 

■ If the concerned entry contains a hne identifier field with 'All hnes' subtype, the notification shall 
be sent to all registered PPs (and shall contain the 'All hnes' hne id subtype, as already stated 
above). 

NOTE 3: The contact list may use both types of targeted PPs, depending on the concerned entry. 

■ If the hst does not containing any line identifier field, the targeted PPs shall depend on the hst and 
on the context (see clause 7.4.10.2.2). 

• Base reset: In case the FP is reset, a 'hst change indication' shall be sent once for each line. 

NOTE 4: In case a hst is lost (i.e. erased from memory) as a result of the base reset, a 'list change indication' is sent 
with <Event multiphcity> field set to '0'. 

Specified line: Line for which the notification is sent (once for each line). 

Targeted PPs: AH PPs attached to the specified line. 

NOTE 5: The purpose of this notification is re-synchronise the PPs with the lists state, in case the lists have 
changed during the base reset. 

• Location registration: A 'hst change indication' shall be sent after location registration, once for each hne the 
PP is attached to (1 FACILITY message per line the PP is attached to). 

Specified line: Line for which the notification is sent (once for each line the PP is attached to). 

Targeted PP: The PP performing location registration (and only this PP). 

NOTE 6: A location registration request ({LOCATE-REQUEST} message) is sent by the PP when the handset is 

switched on. A location registration request could be sent by the PP when it goes back in range (after it 
got out of range) in order to inform the FP that it may have lost some notifications. 

Almost simultaneous events. Several events (i.e. hst changes) occurring almost simultaneously may be the subject of a 
single notification, provided the following rules are respected: 

1) all events notified together shall occur on, or concern, the same list; 

2) all events notified together shall occur on, or concern, the same line (same line id subtype and value). 

Notifications shall be sent by the FP by use of the "generic event notification" procedure. For indication of list change 
and values used in «Events notification» information element, consider table 39. 
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Table 39: Values used within {FACILITY} message for list change indication 



Information element 


FiplH within thp infnrmfition 

I^ICIU Wlllllll IIIC II 1 1 1^1 1 1 lcllll.ll 1 

element 


within the field/IE 


ivui II iciti vc o^tiui 1/ ^ui 1 unci 11 


«Events notification» 


<Event type> 


3 


List change indication 


<tveni suD iype> 


V 
A 


Lisi laeniiTier as inuicaieu in 
clause 7.4.10.3 


<Event multiplicity > 


0..127 


Total number of entries in the list 
(see note 1 ) 


«Call lnformation» 






See note 2 


<ldentifier typo 





Line identifier 


<ldentifier sub typo 


'Line identifier for 
external call', 'Relating 
to', or 'All lines' 


The 'None' value is excluded 


<ldentifier value> 


All 


The line identifier value itself if 
present 

(absent if 'All lines' subtype is used) 


NOTE 1 : 'Event multiplicity' can be extended for values up to 16 383 by using the following extension mechanism: If 
the bit at bit position 8 of the first octet is set to then a second octet will follow, if this bit is set to 1 then 
no further octet will follow. For values greater than 127 the first octet contains the 7 most significant bits 
and the bit at bit position 8 is set to whereas the second octet contains the 7 least significant bits and 
the bit at bit position 8 is set to 1 . For values below 1 28 the first octet contains the 'Event multiplicity' value 
and the bit at bit position 8 is set to 1 indicating that no second octet will follow. Examples: decimal value 
128 is coded as 01 H 80H, decimal value 17 is coded as 91 H and decimal value 1 is coded as 81 H. 

NOTE 2: «Call information» only present if list change indication is related to one or more lines. 



7.4.10.2.2 Mandatory notifications 

In order to allow the display of informatioii in idle mode on PP side, notifications shall be sent by the FP for the 
following lists: 

• Line settings list (defined in clause 7.4.11.4). As indicated in clause 7.4.10.2.1, changes in an entry of this list 
shall be notified to all PPs attached to the line identified by the field 'Line id' of that entry. However for fields 
which are optional or which do not require the PP to update its user interface, notification is optional or 
irrelevant (see clause 7.4.11.4). 

NOTE 1: This allows in particular the PP to immediately update the Une name in other lists entries (e.g. if used 
instead of the line id when the Ust is presented to the user). 

• Internal names list. A change in this list shall at least be notified when a PP modifies the name of another PP 
(if the FP allows it), and the list change notification shall at least be sent to that other PP concerned by the 
change. 

For all other lists, sending of notifications is left free to the implementor. However, the possibly important extra 
processing on FP and PP sides necessary for sending and handling notifications (e.g. if sent for each call) shall be 
carefully taken into account. 

NOTE 2: The present 'List change notification' procedure catmot be used for the missed call Ust as stated in 
clause 7.4.10.2.1. 
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7.4.1 0.3 List identifier codings 

The following list identifier codings are defined: 



87654321 


Meaning 


00000000 


List of supported lists 


0000000 1 


Missed calls list 


000000 10 


Outgoing calls list 


000000 11 


Incoming accepted calls list 


00000 100 


All calls list 


00000 10 1 


Contact list 


00000 110 


Internal names list 


00000 111 


DECT system settings list 


0000 1000 


Line settings list 


0000 100 1 


All incoming calls list 


Ixxxxxxx 


Reserved for proprietary lists 



all other values reserved 

The hsts shall be sorted on the FP, using default criteria for each of them. The default sorting criteria are the following: 

• The "Missed calls", "Outgoing calls", "Incoming accepted call" lists, "All incoming calls list" and more 
generally all call-related hsts shall be sorted by default using the "Date and time" field. 

• The "Contact" list shall be sorted by default using the "Name" field (first criterion). In case the names are 
equal the list should be sorted using the "First name" field (criterion 2). 

• The "Internal names" list shall be sorted by default using the "Number" field (terminal id number). 

• The "Line settings" list shall be sorted by default using the "Line id" field. 

Please refer to the "Start session" command for a definition of the sorting order used for a given field type (this 
definition applies independently of the position of the field in the sorting process: i.e. whether used as "first criterion", 
"criterion 2", etc.). 



7.4.1 0.4 List Access Commands 

The following list access connmands are defined: 



87654321 


Meaning 


PP -> FP 


FP -> PP 


00000000 


start session 


yes 




0000000 1 


start session confirm 




yes 


000000 10 


end session 


yes 


yes 


000000 11 


end session confirm 


yes 


yes 


00000 100 


query supported entry fields 


yes 




00000 10 1 


query supported entry fields confirm - 


yes 


00000 110 


read entries 


yes 




00000 111 


read entries confirm 




yes 


0000 1000 


edit entry 


yes 




0000 100 1 


edit entry confirm 




yes 


0000 10 10 


save entry 


yes 




0000 10 11 


save entry confirm 




yes 


0000 1100 


delete entry 


yes 




0000 110 1 


delete entry confirm 




yes 


0000 1110 


delete list 


yes 




0000 1111 


delete list confirm 




yes 


000 10000 


search entries 


yes 




000 1000 1 


search entries confirm 




yes 


000 100 10 


negative acknowledgement 




yes 


000 100 11 


data packet 


yes 


yes 


000 10 100 


data packet last 


yes 


yes 


Ixxxxxxx 


reserved for proprietary hst access connmands 





all other values reserved 
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Proprietary list access commands shall have list access command codings with most significant bit set to T. 

The "read entries", "read entries confirm" and "search entries confirm" commands use a start index as these command 
may apply to a range of entries within a list. 

The "save entry confirm" command uses a position index as this command applies to one entry. 

Possible error codes are specified for each command from PP to FP. They use negative acknowledgement command, 
with exception of negative start session confirm. 

Additionnally to the general status of a given command and a given hst as described in table 9 for feature [NG1.N.16], 
the PP shall foUow the following more detailed requirements : 



Table 40: PP commands support status per list 



List (with status as given in 
table 9, feature [NG1.N.16]) 


Command (with status as given in table 9, feature [NG1.N.16]) 




Start/end 


Query 


Read 


Edit 


Save 


Delete 


Delete list 


Search 




session 
(M) 


supported 
entry fields 
(0) 


entries 
(M) 


entries 
(M) 


entry (M) 


entry (M) 


(M) 


entries (M) 


Lists of supported lists (0) 


M 


1 


M 




1 


1 


1 


1 


Missed call list (IVI) 


M 





M 




1 


M 


M 





Outgoing call list (0) 


M 





M 




1 


M 


M 





Incoming accepted call list (M) 


M 





M 




1 


M 


M 





All calls list (0) 


M 





M 




1 


M 


M 





Contact list (M) 


M 





M 


M 


M 


M 





M 


Internal names list (M) 


M 





M 


M 


M 


M 


1 





All incoming calls list (0) 


M 





M 


1 


1 


M 


M 





DECT system settings list (M) 


M 





M 


M 


M 


1 


1 


1 


Line settings list (M) 


M 





M 


M 


M 





1 


1 



EXAMPLE: If the PP implements the 'list of supported hst' (optional list), PP shall then implement 'start 

session', 'end session' and 'read entries' commands, other commands for this list are irrelevant. 

Additionally to the general status of a given command and a given list as described in table 9 for feature [NG1.N.16], 
the FP shall follow the following more details requirements : 



Table 41 : FP commands support status per list 



List (with status as given in 
table 9, feature [NG1.N.16]) 


Command (with status as given in table 9, feature [NG1.N.16]) 




Start/end 
session 
(M) 


Query 
supported 

entry fields 
(M) 


Read 
entries (M) 


Edit 
entries 

(M) 


Save 
entry (M) 


Delete 
entry (M) 


Delete 
list (M) 


Search 
entries (M) 


Lists of supported lists (M) 


M 


1 (note 1) 


M 


1 (note 1) 


1 (note 1) 


1 (note 1) 


1 (note 1 ) 


1 (note 1 ) 


Missed call list (M) 


M 


M 


M 


1 (note 1) 


1 (note 1) 


M 


M 


M 


Outgoing call list (0) 


M 


M 


M 


1 (note 1) 


1 (note 1) 


M 


M 


M 


Incoming accepted call list (M) 


M 


M 


M 


1 (note 1 ) 


1 (note 1) 


M 


M 


M 


All calls list (0) 


M 


M 


M 


1 (note 1 ) 


1 (note 1) 


M 


M 


M 


Contact list (M) 


M 


M 


M 


M 


M 


M 


M 


M 


Internal names list (M) 


M 


M 


M 


M (note 4) 


M (note 4) 


M (note 4) 


1 (note 1 ) 


M 


All incoming calls list (0) 


M 


M 


M 


1 (note 1 ) 


1 (note 1) 


M 


M 





DECT system settings list (M) 


M 


M 


M 


M (note 4) 


M (note 4) 


1 (note 1) 


1 (note 1 ) 


1 (note 1 ) 


Line settings list (M) 


M 


M 


M 


M (note 4) 


M 

(notes 3 
and 4) 




(notes 2 
and 4) 


1 (note 1 ) 


1 (note 1) 


NOTE 1 : FP shall answer with negative acknowledgement / 'procedure not allowed'. 

NOTE 2: If not supported, FP shall answer with negative acknowledgement / 'procedure not allowed'. 

NOTE 3: FP shall support the command to offer the possibility to modify a line setting. However, the 'save entry' for 

creating a new line may not be supported by the FP. See clause 7.4.10.4.5.2. 
NOTE 4: Additional requirements apply when a PP is involved in a voice call. FP shall temporarily restrict access to the 

list by the until the duration of the voice call. See clause 7.4.1 0.6 for details. 
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7.4.1 0.4.1 Start and end session 

7.4.10.4.1.1 "Start session" command 

This command from PP requests to start a session to access the specified list in the FP. 



Table 42: Values used within {IWU to IWU} information element 
to request the starting of a list change session 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =start session> 





List access command 




<List identifier> 


O..FFH 


List identifier 




<Sorting fields> 




List of suggested fields for sorting 
the list towards this PP 




<Number of sorting fields> 


0..255 


If 0, the default sorting of the list shall 
be used by the FP (see note) 




<Sorting field identifier 1 > 


0..255 


Suggested field element type used 
for sorting the list (first criterion) 












<Sorting field identifier n> 


0..255 


Suggested field element type used 
for sorting the list, to be used when 
field 1, field n-1 of both compared 
entries are equal (criterion n) 


NOTE: It is recommended to limit the number of requested sorting fields to two (n=2). 



The submitted sorting field identifiers suggest entry fields which should be used by the FP to sort the requested list 
towards this PP in the given session. This suggests to sort the list by "sorting field 1" as first criterion, and then by 
"sorting field 2" as second criterion, when field 1 of both compared entries are equal, and so on. 

For each field type, a sorting order is defined, which applies independently of the position of the field in the sorting 
process: i.e. whether used as "first criterion", "criterion 2", etc. The defined sortings are as follows: 

• For fields of type "Number" (including terminal id numbers), "Name", "Line name", "First name", or "Contact 
number", the case insensitive alphanumerical order shall be used. 

NOTE: The alphanumerical order can only be defined on a subset of the UTF-8 encoded characters. This subset 
and the associated order depend on the locale used. 

• For fields of type "Date and time", the ante-chronological order shall be used (highest index for the oldest call, 
lowest index for the newest call). 

• For fields of type "Line id", the ascending numerical order shall be used. 

If a field used for sorting is included several times in the entries, the FP shall decide which instance of the field is used 

for the sorting. 

EXAMPLE; If the PP requests contact list to be sorted with the contact number field and the list entries include 
one "mobile" and one "work" contact number fields, the FP may use the "mobile" instance of the 
field for sorting. Entries with "mobile" numbers may appear first in the list then entries with 
"home" numbers. Please note that this additional "sub-sorting" performed by the FP might be 
unknown or a bit inconvenient to the user (on PP side). As a consequence, the PP should request 
such sorting only if strictly necessary. 

If the <Number of sorting fields> is equal to 0, the FP shall use the default sorting of the list. No sorting field identifier 
is sent in this case. 
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7.4.10.4.1.2 "Start session confirm" command 

This command from FP to PP confirms or rejects the start of the session. 



Table 43: Values used within {IWU to IWU} information element to confirm or 
reject the starting of a list change session 



Information element 


Field within the information 
element 


Standard values 
witnin tne Tieiu/ic 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =start session 


1H 


List access command 




confirm> 








<List identifier> 


O..FFH 


List identifier 




<Session identifier> 


0..127 


Session identifier (see note 1) 




<Total number of available 


0..127 


Number of available entries in list 




entries> 




requested by the PP (see note 1) 




<Discriminator type> 


OOH, 01 H 


Undefined, EMC (see note 2) 




<Discriminator> 


OOH..FFH 


EMC value high byte 




<Discriminator> 


OOH..FFH 


EMC value low byte 




<Start session reject reason> 


O..FFH 


Reject reason in case of reject 




<Sorting fields> 




List of fields used for the actual 
sorting the list towards this PP 




<Number of sorting fields> 


0..255 






<Sorting field identifier 1 > 


0..255 


Field element type used for the 
actual sorting the list (first criterion) 












<Sorting field identifier n> 


0..255 


Field element type used for the 
actual sorting of the list (criterion n) 


NOTE 1 : Total number of available entries' and 'session identifier' can be extended for values up to 16 383 by using 
the same mechanism as for 'Event multiplicity'. See note at table 39. 


NOTE 2: Discriminator type set to '1 ' (= ElVIC) indicates the support of proprietary list access commands, of 
proprietary lists and of proprietary list fields. For distinguishing proprietary elements from different 
manufacturers, the ElVIC is given in the following two octets. In case Discriminator type is set to '0', the 


following two octets are do not care. The PP shall not use proprietary elements in case either the 
Discriminator type is '0' (= Undefined) or the EMC is different from the own one. Proprietary elements 
shall have identifiers with the most significant bit set to '1'. 



The session identifier shall be unique between the FP and one PP. It identifies the access to one hst for the PP, which 
has started the session. The FP shall at least support two session at a time to one PP. 

The submitted list entry field identifiers are used to indicate the entry field which is used by the FP to sort the requested 
list towards this PP in the given session. The FP may choose other entry fields than the ones suggested by the PP in the 
'start session' command (e.g. 'name' instead of 'first name' in contact hst). The sorting capabilities of the FP depend on 
the implementation of the FP. 

For list entry field identifiers see clause 7.4.10.5.1. 

If start session is confirmed the reject reason shall not be evaluated. 

Even if the default sorting is required by the PP in the "Start session" command (using '0' as value for <Number of 
sorting fields>), the FP shall confirm the sorting fields which were actually used for sorting the hst (and which shall be 
the ones defined as "default" sorting fields in clause 7.4.10.4.1.1). 

Possible error cases: 

If start session is rejected, the session identifier shall be set to 0, and the field reject reason shall indicate the appropriate 
reason. 

If a sorting field identifier is not valid, the submitted sorting field identifier shall be ignored by the FP. Nevertheless the 
FP indicates the chosen sorting field identifiers in the start session confirm. 
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Start session reject reason: 

Bits 87654321 Meaning 

00000000 not enough resources 

00000001 list already in use by another session 

1 list not supported 

0000001 1 maximum number of sessions supported by the FP reached 
all other values reserved 

If a FP allows only 1 started session for a given list (to avoid potential collision scenarios), the FP shall use the reject 
reason "Ust already in use by another session". 

If a PP attempts to start a session and the FP has no more resources to handle this start session, the FP shall use the 
reject reason "maximum number of sessions supported by the FP reached". 

7.4.10.4.1.3 "End session" command 

This command from PP or FP ends the specified session. 



Table 44: Values used within {IWU to IWU} information element 
to request the end of a list change session 



information element 


Field within the information 
element 


Standard values 
within the fleld/IE 


Normative action/comment 


«IWU to IWU» 


<Lengtfi of content> 


L 


Lengtin of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =end session> 


2H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using tlie same mecfianism as for 'Event 
multiplicity'. See note at table 39. 



This command is recommended to be sent by PP and FP to request end of session. 
The session(s) between a PP and FP shall at latest be terminated with call release. 

Remaining locked entries (see edit procedure) shall be unlocked either with the end session connmand or at latest with 
call release ({CC-RELEASE} message). 

Possible error cases: 

If session identifier is wrong the connmand should be ignored by the receiver. 

7.4.1 0.4.1 .4 "End session confirm" command 

This command from PP or FP confirms the ending of the specified session. 



Table 45: Values used within {IWU to IWU} information element 
to confirm the end of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Lengtli of content> 


L 


Lengtfi of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =end session 


3H 


List access command 




confirm> 








<Session identifier> 


1..127 


Session identifier (see note) 



NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using tine same mechanism as for 'Event 
multiplicity'. See note at table 39. 



Reject of end session request shall not be possible. 
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7.4.1 0.4.2 Query supported entry fields 
7.4.10.4.2.1 "Query supported entry fields" command 

This command from PP queries the fields which are supported or not in the entries of a given list in the FP. 



Table 46: Values used within {IWU to IWU} information element 
for the "Query supported entry fields" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command = query supported 
entry fields> 


4H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using tine same mechanism as for 'Event 


multiplicity'. See note at table 39. 







Possible error cases: 

If session identifier is wrong, the FP shall answer with negative acknowledgement reject reason 'invalid session 
number'. 

7.4.1 0.4.2.2 "Query supported entry fields confirm" command 

This command from FP confirms the query of supported fields which are supported or not in the entries of a given Ust 
in the FP. 

The FP submits the supported entry field identifier and shall group them in editable and non-editable fields. 



Table 47: Values used within {IWU to IWU} information element 
for the "Query supported entry fields confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command = query supported 
entry fields confirm> 


5H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 




<number of editable entry fields> 


0..255 


Number of editable entry fields 




<List entry field identifier 1 > 


0..255 


Supported field element type 












<List entry field identifier n> 


0..255 


Supported field element type 




<number of non-editable entry 
fields> 


0..255 


Number of non-editable entry fields 




<List entry field identifier 1 > 


0..255 


Supported field element type 












<List entry field identifier n> 


0..255 


Supported field element type 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using the same mechanism as for 'Event 
multiplicity'. See note at table 39. 



When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

If a field is included more than once in the entries of the list (FP decision), all instances of this field shall appear in the 
"query supported entry fields confirm" (field identifier is repeated in the confirm). This allows PP to be aware how 
many instances of a field shall be included during a further save command. 

For hst entry field identifiers see clause 7.4.10.5.1. 
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7.4.10.4.3 Read entries 

7.4.1 0.4.3.1 "Read entries" command 

This command from PP requests to read a range of consecutive entries in the list, or only a subset of the fields of these 
entries. The list here shall be understood as the Ust resulting from the initial sorting of the list as specified by the FP in 
the "Start session confirm" command. 

NOTE 1: Range can be limited to one entry. 

In case the <mark entries request> field is used with a non-zero value, the requested subset of fields may be empty. In 
that case, a 'Read entries confirm' command with no data packet shall be returned by the FP (see clause 7.4. 10.4.3.2). 



Table 48: Values used within {IWU to IWU} information element for "Read entries" command 



Information element 


Field within the Information 
element 


Standard values 
within the fleld/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command =read entries> 


6H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note 1) 


<Start index> 


0..127 


Start index (see note 1) 


<Direction (bit 8)> 
<Counter (bits 1 to 7)> 


0..1 
1..127 


Direction of the read (forward or 
backward) 

Number of requested entries 


<Mark entries request> 


OOH, 7FH, FFH 


Flag for requesting resetting (or 
setting) of the 'Read status' field for 
all read entries (see note 2) 


<List entry field identifier 1> 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE 1 : 'Session identifier' and 'start index' can be extended for values up to 16 383 by using the same 

meclianism as for 'Event multiplicity'. See note at table 39. 
NOTE 2: This field is used (with value 7FH) to indicate that the entries read by the PP are considered as read by 

the user, or will necessarily be read by the user. The <mark entries request> field is only considered if the 

list contains a 'Read status' field. Otherwise it is present but ignored on both sides. See also below 

subsection 'Mark entries request (octet)'. 
NOTE 3: 'List entry field identifier' values are defined for each list separately. 



Start index: 

The start index is the first index of the range of requested entries. 

Bits 7 6 5 4 3 21 Meaning 

last entry 

other values Ust entry 

Direction and Counter (octet): 

Bits 87654321 Meaning 

Oxxxxxxx forward (in ascending list index order) 
Ixxxxxxx backward (in descending list index order) 

The response contains data packets with list entries in order of ascending list index, regardless of whether counter 
indicated forward or backwards and always includes the entry with list index=start index. 

EXAMPLE: In case 2 entries are requested 'backwards' with start index 5, the data packets shall include the 
entries with indices 4 and 5, with entry 4 transmitted first. 
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Mark entries request (octet): 

This field applies to a list having a 'Read status' field, and is otherwise ignored on both sides. This field allows the PP to 
request from the FP that all read entries 'Read status' field be reset (when value '7F'H is used), or that all read entries be 
set (when value 'FF'H is used). Value 'OO'H indicates that the 'Read status' field for all read entries must be left 
unchanged. 

NOTE 2: Only the 'missed call list' and the 'All incoming call list' have a 'Read status' field. For the 'All incoming 
call Ust' the mark entries request is only applied to missed call entries (incoming accepted calls have a 
fake 'Read status' field with a frozen value of '0'). 

When the value '7F'H or 'FF'H is used (mark all entries as read or as unread), the subset of requested fields may be 
empty. In that case the 'Read entries' command is only used by the PP to mark entries as read or as unread in the list. 

Bits 87654321 Meaning 

00000000 all read entries 'Read status' field shall be left unchanged 

01111111 all read entries 'Read status' field shall be reset (i.e. marked as read) 

11111111 aU read entries 'Read status' field shall be set (i.e. marked as unread) 

AH other values reserved 

This field allows the PP to follow various strategies when presenting entries to the user, including the following ones: 

Single-read strategy (for simple PPs): the PP always use value '7F'H so that all entries read from the FP have always 
their 'Read status' field reset. 

Enhanced two-read strategy ('Browsing then reading'). A PP using this strategy always uses value 'OO'H for browsing 
(typically reading only part of the fields in that step). When a user selects an entry to actually read it, the PP re-reads the 
entry from the FP, and uses value '7F'H for resetting the 'Read status' field of that entry. 

NOTE 3: The PP could also request all fields of the read entries in the browsing step, in order to speed up the 
second step (caching fields not shown in the first step). 

List entry field identifier : 

When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

In case the 'start index' is invalid, the FP shall answer with negative acknowledgement, reject reason 'invalid start index'. 
This includes the case where the Ust is empty. 

In case the index range given with 'counter' is invaUd, the FP shall return the existing elements in the range. 

In case an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next 
requested field. 

7.4.1 0.4.3.2 "Read entries confirm" command 

This command from FP confirms the read command with the corresponding entry/entries with one or several specified 
fields. Corresponding entry/entries are sent along in data packets. 
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Table 49: Values used within {IWU to IWU} information element for "Read entries confirm" command 



inTuriTiaiiun cicincni 


riciQ wiinin in6 inTurniaiion 


Olanuaru ValUcS 
Wlllllll lllc IIClU/IC 


HOriTlallVc aCllOn/CUIIIIIIcni 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =read entries 


7H 


List access command 




confirm> 








<Session identifier> 


1..127 


Session identifier (see note) 




<Start index> 


1..127 


Start index (see note) 




<Counter> 


0..127 


Number of delivered entries 


NOTE: 'Start index' and 'Session identifier' can be extended for values up to 16 383 by using the same 


mechanism as for 'Event multiplicity'. See note at table 39. 





Counter (octet): 

'Counter' returns the number of returned list entries. 

Bits 87654321 Meaning 

Oxxxxxxx number of returned entries 

Bit 8 shall remain unset consistently with "Read entries" command format (see clause 7.4.10.4.3.1). 

If a given field is included more than once in the entries, all instances of this field shall be included in the "Read entries 
confirm" command. 

'Start index' shall always indicate the smallest index value of the list response. 
Content of list entry is transmitted in data packets. 

In case the subset of fields requested in the 'Read entries' command was empty, the <Counter> field shall be set to '0' 
and no data packet shall be sent (see also clause 7.4.10.4.3.1). 

7.4.10.4.4 Edit entry 

7.4.10.4.4.1 "Edit entry" command 

This command from PP requests to read and lock only one entry. 



Table 50: Values used within {IWU to IWU} information element for "Edit entry" command 



Information element 


Field witiiin the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


03H 


List access 




<Command =edit entry> 


8H 


List access command 




<Session identifier> 


1..127 


Session identifier (see note) 




<Entry identifier> 


1..127 


Entry identifier (see note) 




<List entry field identifier 1 > 


0..255 


Requested field element type 












<List entry field identifier n> 


0..255 


Requested field element type 


NOTE: 'Session identifier' and 'entry identifier' can be extended for values up to 16 383 by using the same 
mechanism as for 'Event multiplicity'. See note at table 39. 



A PP may edit some or all the fields of an entry (independently of whether the "editable" property of the field is set or 
not). Whether a field element is editable or not is indicated for each field in the response message (i.e. in the "editable" 
property of each field). 

In contrast to 'read entries', the "edit entry" list access command contains a reference to a single list entry ("entry 
identifier" field). 
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When receiving an "edit entry" command, the FP shall prevent other PPs from changing the specified list entry 
(negative acknowledgement with reject reason 'temporarily not possible') until the sending PP has sent the 
corresponding "save entry" command, or until the session is terminated. In other words, the FP shall temporarily 
prevent "save entry" and "delete entry" commands for the entry from being used by other PPs, as well as the "delete 
list" command. 

'List entry field identifier' values are defined for each list separately. 

When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

In case an unknown entry identifier is requested, the FP shall answer with negative acknowledgement, reject reason 
'entry not available'. 

In case an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next 
requested field. 

The FP may not allow editing entries on a dedicated list (especially for call lists); the FP should send negative 
acknowledge with reject reason 'procedure not allowed' in this case. This also mean save will neither be allowed on 
those lists. 

7.4.1 0.4.4.2 "Edit entry confirm" command 

This command from FP confirms the edit command with the corresponding entry with one or several specified fields, 
and locks this entry against access from other PPs. Corresponding entry is sent along in data packets. 



Table 51 : Values used within {IWU to IWU} information element for "edit entry confirm" command 



Information element 


Field within tiie Information 
element 


Standard values 
within the fleld/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command =edit entry confirm> 


9H 


List access command 


<Session ldentifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using the same mechianism as for 'Event 
multiplicity'. See note at table 39. 



Content of list entry is transmitted in data packets. 

When a non-editable field is requested by a PP, the FP shall return it. This is not considered as an error case, the 
"editable" property will indicate whether this field element is editable or not. 

If a field is included more than once in the entry, all instances of this field shall be included in the "edit entry confirm" 
command. 

7.4.10.4.5 Save entry 

7.4.1 0.4.5.1 "Save entry" command 

This command from PP requests to save the entry in the list identified by the specified entry identifier, or to add a new 
entry to the list. Corresponding entry is sent along in data packets. 

The list entries which are saved shall have been requested via 'edit' before in the same session, except for creation of a 
new entry. 

The 'save' transaction shall contain all fields or a subset of the fields which were submitted in the 'edit' transaction. 
Other fields (not edited and not saved) remain unchanged in the FP. 
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Table 52: Values used within {IWU to IWU} information element for "Save entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R blt> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = save entry> 


AH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


0..127 


Entry identifier (see note) 


NOTE: 'Session identifier' and 'entry identifier' can be extended for values up to 16 383 by using the same 
meclianism as for 'Event multiplicity'. See note at table 39. 



Content of list entry is transmitted in data packets. 
Entry identifier: 

Bits 7 6 5 4 3 21 Meaning 

not yet assigned entry identifier (new entry proposed by the PP) 

other values assigned entry identifier (this entry identifier shall already exist in the Ust) 

If a new entry has to be created, the PP shall indicate this by using the entry identifier OOH. It is recommended that all 
fields (editable or not) of the new entry are set by the PP. If the PP omits some of the fields in the save command, the 
FP shall automatically assign a default value to those fields after the save command. In this case, the end FP shall assign 
a new entry identifier for the entry and submit it in the following 'save entry confirm'. 

The new or modified entry shall be inserted in the list by the FP taking into account the sorting criteria for this list. 
Content of Ust entry is transmitted in data packets. 

If the previously started edit procedure has to be terminated without changing the list entry, PP shall perform the 'save 
entry' procedure with only one empty 'last data packet' following after 'save entry'. 

In case several fields of the same type in one entry were received during 'edit', PP shall send with 'save' all received 
fields of this type. 

A PP may request the reset of the field of an entry by setting the field length to 1 (only octet 3 available in entry field). 
The field itself is not removed from the FP list entry. It has to be noted that resetting some fields in some lists can be 
dangerous and should be carefully controlled by the PP. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown entry identifier of the list is requested (except 0), the FP shall answer with negative acknowledgement, 
reject reason 'entry not available'. 

If a PP attempts to save an entry with a field content which cannot be accepted, (e.g. for a field whose contents are only 

allowed once in the list like line-id in the "Line settings" list or when too many instances of a field are saved in the same 
entry), the FP shall reject the command with a negative acknowledgement, with reject reason "content not accepted". 

If a PP attempts to add a new entry in a list which cannot accept an additional entry, the FP shall reject the command 
with a negative acknowledgement, with reject reason "list full". 

7.4.1 0.4.5.2 "Save entry confirm" command 

This command from FP confirms the save of one entry in a Ust and returns the position index where the entry was 
saved. 
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Table 53: Values used within {IWU to IWU} information element for "Save entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = save entry confirm> 


BH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


1..127 


Entry identifier (see note) 


<Position index> 


1..127 


Position index (see note) 




<Total number of available 
entries> 


0..127 


Number of available entries in list 
after saving (see note) 


NOTE: 'Session identifier', 'position index', 'entry identifier', and 'total number of avaiiabie entries' can be 

extended for values up to 16 383 by using the same mechanism as for 'Event multiplicity'. See note at 
table 39. 



The position index indicates the (possibly new) index of the entry in the Hst. 

The 'Total number of available entries' reflects the updated number of entries in the list after save is performed. It is 
useful especially when saving (creating) a new entry. 

Possible error cases: 

Entry fields which were not indicated as editable shall not be sent back with changes within the data packet messages 
belonging to the save entry procedure. 

In case changes in non-editable fields or a change of a not previously requested (edit) entry, the FP shall send negative 
acknowledge with reject reason 'procedure not allowed'. 

FP may not allow saving new entries for a dedicated Ust (especially for call lists), the FP should send negative 
acknowledge with reject reason 'procedure not allowed' in this case. 

The FP may also not allow the saving of a new entry in the Une settings list. Same negative acknowledgement shall be 
used. 

NOTE: For lists that allow creation of a new entry, it is supposed that all fields are editable on FP side. 
7.4.10.4.6 Delete entry 

7.4.10.4.6.1 "Delete entry" command 

This command from PP requests to delete one entry in a Ust. 



Table 54: Values used within {IWU to IWU} information element for "Delete entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command =delete entry> 


CH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


1..127 


Entry identifier (see note) 


NOTE: 'Session identifier' and 'entry identifier' can be extended for values up to 1 6 383 by using the same 
mechanism as for 'Event multiplicity'. See note at table 39. 



The 'delete entry' command is not allowed for the following lists: 

• 'List of supported Usts', and 

• 'DECT system settings list'. 
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The 'delete entry' command for the 'Internal names list' shall respect the following rules: 

• it shall be interpreted as a request for de-registering from the system the PP hsted in the entry to be deleted 
(see clause 7.4.11.2); 

• if this PP is involved in a call, the FP shall reject the 'delete entry' command by sending a negative 
acknowledgement with reject reason, 'temporarily not possible' (as defined in clause 7.4.10.6). 

The FP may disallow the 'delete entry' command for 'Line settings list'. See possible error case for answer. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown entry identifier of the hst is requested, the FP shall answer with negative acknowledgement with reject 
reason 'entry not available'. 

If the PP sends a 'delete entry' command in a case where it is not allowed (see above), the FP shall answer with negative 
achnowledgement with reject reason, 'procedure not allowed'. 

7.4.1 0.4.6.2 "Delete entry confirm" command 

This command from FP confirms the deletion of an entry in a hst. 



Table 55: Values used within {IWU to IWU} information element for "Delete entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = delete entry 
confirm> 


DH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Total number of available 

entries> 


0..127 


Number of available entries in list 

after deletion (see note) 


NOTE: 'Total number of available entries' and 'session identifier' can be extended for values up to 16 383 by 
using the same mechanism as for 'Event multiplicity'. See note at table 39. 



7.4.10.4.7 Delete list 

7.4.10.4.7.1 "Delete list" command 

This command from PP requests the deletion of a complete list. 

Table 56: Values used within {IWU to IWU} information element for "Delete list" command 



information element 


Field within the information 

element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command =delete list> 


EH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using the same mechanism as for 'Event 
multiplicity'. See note at table 39. 



Delete list means deletion of all entries. The list itself is still available. 
Use of the 'Delete list' command is not allowed for the following hsts: 
• 'List of supported hsts'. 
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• 'Internal names list', 

• 'DECT system settings list', and 

• 'Line settings Ust' (see 'possible error cases' clause). 
Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown list identifier is requested (including Ust of supported Ust), the FP shall answer with negative 
acknowledgement, reject reason 'procedure not allowed'. 

In case the FP rejects the 'delete list' command, it shall answer with a negative acknowledgement, with reject reason = 
'procedure not allowed'. This negative acknowledgement shall be used in particular if the 'delete list' command is used 
for one of the Usts for which this command is not allowed (see above). 

7.4.1 0.4.7.2 "Delete list confirm" command 

This command from FP confirms the deletion of a complete Ust. 



Table 57: Values used within {IWU to IWU} information element for "Delete list confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length) of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command =delete list confirm> 


FH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using the same mecfianism as for 'Event 
multiplicity'. See note at table 39. 



7.4.10.4.8 Search entries 
7.4.10.4.8.1 "Search entries" command 

This command from PP requests to read a range of consecutive entries in the list, beginning with an entry matching a 
search criterion. The list here shall be understood as the list resulting from the initial sorting of the list as specified by 
the FP in the "Start session confirm" command. 

For the 'Search entries' conmiand, the requested subset of fields should not be empty. 
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Table 58: Values used within {IWU to IWU} information element for "Search entries" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = search entries> 


10H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note 1) 


<IVIatching option> 


OOH to 06H 


First part of the search criterion 


rf^Qoarr'hoH v/sliio 
voccii Lfi icu vdiuc; ^ 




OcLfUl lU \Ja\ L Ul Li lU oUdl Ul 1 Ol 1 LCI Iwl 1 , 

Always coded as a string 


<String length> 


1..255 




<String content 0> 




UTF-8 coded characters 








<ouiny conienT n> 




u 1 r-o coueu cnaraciers 


<Direction (bit 8)> 
<Counter (bits 1 to 7)» 


n i 
U..1 

1..127 


Direction of the read (forward or 
backward) 

Number of requested entries 


<Mark entries request> 


OOH, 7FH, FFH 


Flag for requesting resetting (or 
setting) of the 'Read status' field for 
all read entries (see note 2) 


<List entry field identifier 1 > 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE 1 : 'Session identifier' can be extended for values up to 1 6 383 by using the same mechanism as for 'Event 

multiplicity'. See note at table 39. 
NOTE 2: This field is only considered if the list contains a 'Read status' field. Otherwise it is present but ignored on 

both sides (see also clause 7.4.10.4.3, 'Read entries'). 
NOTE 3: 'List entry field identifier' values are defined for each list separately. 



In the list access command 'search entries', the submitted searched value contents together with the matching option 
define the search criterion. 

FP answers with hst entries beginning with the first matching entry, but it does not generate a new list for the result. A 
matching entry shall be understood with the matching option taken into account. 

The "Search entries" command shall be considered successful if at least one entry is found that matches the search 
criterion, and even if there are less than <counter>-l entries after the matching entry in the list. See "Search entries 
confirm" command/particular cases for the case the search does not succeed (no entry found at all). 

The command 'search entries' is in principle similar to 'read entries' with the exception, that instead of 'start index' the 

'searched value' is used. 



Matching option: 

Bits 87654321 Meaning 

00000x00 exact match with whole target field required 

00000x01 exact match as with OOH option tried, current start index returned if exact match fails 

00000x10 exact match as with OOH option tried, previous start index returned if exact match fails 

000001 XX case sensitive search required 
all other values reserved 



If 'OO'H matching option is used, the FP shall only succeed if it finds an entry in the hst with first sorting field value 
equal to the searched value, and shall return a "not matching" answer otherwise (see "not matching case section" in 
clause 7.4.10.4.8.2). 

NOTE 1: This option is especially useful for the PP to retrieve a specific entry with no human intervention. 
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'Ol'H and '02'H options allow to search the "nearest" alphanumerical entry/entries in the list to the searched value (for 
example, option 'Ol'H could be convenient if user/PP only enters "s" when searching for all entries starting with "s" ). 

If 'Ol'H matching option is used, the FP shall only succeed if either the exact match succeeds (as with option OOH), or if 
the end of the list was not reached when the exact match failed. The current entry index shall be returned as start index 
of the returned range. If the end of the list was reached when the exact match failed (there is no current entry anymore), 
the FP shall return a "not matching" answer (see "not matching case section" in clause 7.4.10.4.8.2). 

If '02'H matching option is used, the FP shall only succeed if either the exact match succeeds (as with option OOH), or if 
the current entry when the exact match failed was not the first entry of the list. The "previous index" = "current entry 
index -1" shall be returned as start index of the returned range. If the current entry when the exact match failed was the 
first entry of the Ust, the FP shall return a "not matching" answer (see "not matching case section" in 
clause 7.4.10.4.8.2). 

EXAMPLE 1: If "Smi" is the searched value, with matching option 'Ol'H, and there is no entry with "Name" field 
equal to "Smi" in the list, exact match will fail on the first entry ranked after "Smi" in the list when 
using the alphanumerical order. This entry is the so-called "current entry" and may have e.g. 
"Smith" as "Name" field value, or any other value. 

EXAMPLE 2: If "s" is the searched value, with matching option 'Ol'H, FP will answer in search confirm with the 
index of the first entry starting with a "s". If there are none, FP will answer with index of the first 
entry starting with a "t" and so on. 

In addition to the matching options ('OO'H, 'Ol'H, '02'H), the search may be case sensitive or not if bit 3 is set or not. 

Searched value: 

The FP shall use the 'searched value' as search criterion in the entry field which was used as first criterion by the FP for 
sorting the list; this sorting field is indicated to the PP in the 'Start session confirm' command. 

In case a numerical value is searched, the string content fields shall contain the IA5-coded decimal representation of the 
value (e.g. in case of searching for Line id =12, the string content is 'Sl'H '32'H). 

NOTE 2: This particular coding of numerical values does not imply anything about the underlying sorting order of 
the list, which depends on the sorting fields defined for the session and on their types (see "Start session" 
command). 

Counter (octet): 

See the "Read entries" command (see clause 7.4.10.4.3), as the same definition applies here. 
List entry field identifier : 

When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

In case an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next 
requested field. 

7.4.1 0.4.8.2 "Search entries confirm" command 

This command from the FP specifies the start index of the range of entries found as a result of the "Search entries" 
command, and the number of returned entries. Corresponding entry/entries are sent along in data packets. 
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Table 59: Values used within {IWU to IWU} information element 
for "Search entries confirm" command 



Information element 


PICIU Wlllllll lllc II IIUI IlldllUI 1 
CICI 1 Id 1 1 


OlallUaru VdlUco 
within tli^ fi^lri/IP 


lYUI llldll VC dlfllUI l/l«UIIIIIICl 11 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = search entries 
confirm> 


11H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Start index> 


1..127 


Start index of the range of returned 
entries (see note) 


<Counter> 


0..127 


Number of returned entries 


NOTE: 'Session identifier' and 'start index' can be extended for values up to 16 383 by using tfie same 
mechanism as for 'Event multiplicity'. See note at table 39. 



Counter (octet): 

'Counter' returns the number of returned list entries. 

Bits 87654321 Meaning 

Oxxxxxxx number of returned entries 

Bit 8 shall remain unset consistently with "Read entries" command format (see clause 7.4.10.4.3.1). 
Start index returns the index of the first returned list entry. 
Content of Ust entry/entries is transmitted in data packets. 
Not matching case: 

If no entry is found that matches the search criterion, the <counter> field value shall be set to zero. No data packet shall 
be sent. 

7.4.10.4.9 Negative Acknowledgement 

This command from FP rejects the previous command with a reject reason. 



Table 60: Values used within {IWU to IWU} Information element for "Negative Acknowledgement" 

command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command=negative 
acknowledgement > 


12H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Reject reason> 


0..255 


Reject Reason 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note at table 39. 
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Reject reason: 



Bits 87654321 



Meaning 



00000000 
0000000 1 
000000 10 
000000 11 
00000 100 
00000 10 1 
00000 110 
00000 111 
0000 1000 
0000 100 1 
0000 10 10 
0000 10 11 
all other values 



invalid range 
entry not available 
invalid session number 
temporarily not possible 
entry format incorrect 
invalid start index 
procedure not supported 
procedure not allowed 
content not accepted 
list full 
incorrect PIN 
PIN code required 
reserved 



In case of 'invalid session number', the invalid session identifier of the acknowledged command is used in the negative 
acknowledgement. 

7.4. 10.4.10 Data packet / Data packet last 
These packets allow to send data content along with a command. 

Table 61 : Values used within {IWU to IWU} information element for "Data packet" command 



Information element 


Field within the Information 
element 


Standard values 
within the fleld/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Dlscrimlnator> 


03H 


List access 


<Command =data packet / data 
packet last> 


13H/14H 


List access command 


<Session identifier> 


1..127 


Session Identifier (see note) 


<Data content byte 0> 


C. 255 


Content first byte 








<Data content byte n > 


0.. 255 


Content last byte 


NOTE: 'Session identifier' can be extended for values up to 1 6 383 by using the same mechanism as for 'Event 
multiplicity'. See note at table 39. 



'Data packet last' is used if no more data will be sent for this response. 
Data content is structured as follows: 
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Table 62: Data content structure in the "Data packet" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Entry identifier for 1^' entry> 


0..127 


Identifier of the entry (see notes 1 

and 2) 


<Entry length> 


0..127 


Length (see note 1 ) 


<Entry field identifier 1 > 


0.. 255 




<Entry field length> 


0..127 


Length (see note 1 ) 


<Entry field content 0> 












<Entry field content i> 






<Entry field identifier 2 > 


0.. 255 










<Entry field identifier n > 


0..255 




<Entry field length> 


0..127 


Length (see note 1 ) 


<Entry field content 0> 












<Entry field content j> 






<Entry identifier for 2"° entry> 


1..127 


Identifier of the entry (see note 1 ) 


<Entry length> 


0..127 


Length (see note 1 ) 








Continues with further entries 






N0TE1 : 'Entry identifier', 'entry lengtli', and 'entry field length' can be extended for values up to 1 6 383 by using 

the same mechanism as for 'Event multiplicity'. See note at table 39. 
NOTE 2: 'Entry identifier' value is used only when performing a 'save entry' command to save a new entry. 



The data content is distributed over several 'data packet' messages. One entry field might be distributed over more than 
one data packet. 

When several entry field identifiers are specified within the data packet command, these field identifiers shall be 
ordered in ascending numerical order. 

NOTE : This is vaUd for example in the 'read entries confirm', 'edit entry confirm', 'save entry' and 'search entries 
confirm' related data packets commands. 

The maximum information length of a LAPC UI frame is 63 octets (see EN 300 175-4 [4]). As a consequence, each 
"Data packet" and "Data Packet last" commands can carry up to 56 octets in data content, as the header of "Data packet" 
message is 7 octets length. 

Table 63: Header message structure of "Data packet" command 





Octet: 


Transaction Identifier Protocol Discriminator 


1 


Message Type = {IWU-INFO} 


2 


Information element = «IWU to IWU» 


3 


Length of contents; L (octets) 


4 


Protocol Discriminator = List Access 


5 


Command = data packet 


6 


Session identifier 


7 



If the data content exceeds the 56 octet limit, the data content shall be segmented into two or more data packets and 
these data packets shall be transmitted consequently. 



ETSI 



167 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



IWU-lnfo «IWU to IWU» 



Data packet (session id i) 



id 1 



igi 



Content 1 



IWU-lnfo «IWU to IWU» 



IWU-lnfo «IWU to IWU» 



Data packet (session id i) 



Data packet last (session id i) 



End content 1 


id2 


Ig2 


Content 2 


ids 


Ig3 


Content 3 



Ig1 bytes 



Entry 1 



Ig2 bytes 



Entry 2 





Entry field 1 




Entry field 2 






Entry field i 


Eid1 


Lgf1 


Fcontenti 


Eid2 


Lgf2 


Fcontent2 




Eid i 


Lgfi 


Fcontenti 



Figure 55: Example of one entry distributed over two data paclcets 

The following notations are used in the figure 55 above: 

• idl, id2, id3: entry identifier for entry 1, entry 2 and entry3. 

• Igl, lg2, lg3: entry length for entry 1, entry 2 and entry 3. 

• Contentl, Content 2, Content3: entry content for entry 1, entry 2 and entry 3. 

• Eidl, Eid2, Eid3: field identifier for field 1, field 2 and field 3 of entry 1. 

• Lgf 1 , Lgf2, Lgfi: field length for field 1 , field 2, . . . .field I of entry 1 . 

• Fcontenti, Fcontent2, Fcontenti: field content of field 1, field content of field 2, . . .field content of field I of 
entry 1. 

For entry field contents see clause 7.4.10.5.1. 

7.4.1 0.5 Lists and entry fields 

In the following, the entry field identifiers for various lists are defined. 

Proprietary Ust fields shall have entry field identifiers with the most significant bit set to T. 

7.4.10.5.1 Fields description 

For the fields described in the following clauses: 

Field identifier octet: 

This field value depends on the list the field is used in, and is indicated for each list in the Ust definition. 
Length octet and related extension bit: 

The extension bit of the length octet of a field shall be set to 1 if the length is inferior to 128. If the length is equal or 
superior to 128, more than one byte is used for the field length, the highbyte shall be send before the lowbyte (e.g. T is 
coded as 81H, '128' is coded as OIH 80H). 
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The length value (bits 1 to 7 if extension bit is set) shall be the set to the number of octets in the field starting 
immediately after the last length octet. In particular, it shall include the properties octet defined below. 

Properties octet and related extension bit: 

For some fields, an "editable" property bit exists. The "editable" property bit is set to "1" by the FP to indicate to the PP 
if the field of this entry can be further modified by the PP during a save conamand. If so, the PP may modify the value 
(octet 4 and more) and/or the property bits (octet 3) of the field in a further save command. 

The "editable" bit itself can not be modified by the PP (even if set to 1'). Any modification of this bit shall be 
disregarded by the FP. When creating a new entry (with a save command from PP to FP), the PP may set the "editable" 
property to any value ('0' or '1'). The FP will ignore this value and set it to the desirable value. 

NOTE I: The "editable" bit should be set to 'I' by the FP only when strictly necessary. For example call-related 
lists entry fields should not be editable. Contact list entry fields should be editable. 

The "editable" property bit does not restrict the edit command itself. Any fields (editable or not) can be edited via edit 
command from the PP. The "editable" property bit prevents modification on this field during the next save entry 
cormnand. 

The "editable" property bit does not restrict the use of the 'edit' command itself, which is provided for editing an entry 
as a whole. The PP should prevent edition of non-editable fields (i.e. with "editable" property reset), to avoid misleading 
the user. However, modifications on these fields shall be disregarded by the FP during the next save entry command 
anyway. 

The "PIN protected" property bit allows the FP to protect the field against unauthorised modification by mandating PIN 
code entering before performing a save command on the field. See clause 7. 4. 11.1 for details. 

NOTE 2: Only editable fields (with "editable" property set to 1) may need to be 'PIN protected'. 

Other property bits shall be set correctly by the PP when using the 'save' command. 

Error cases are described for each command in dedicated clauses (see clause 7.4.10.4). 



7.4.10.5.1.1 



Field 'List identifiers' 



Bits 



0/1 



0/1 



Field identifier = List identifiers 



Length (L) 



1 supported list identifier 



2^ supported list identifier 



Octet 
1 
2 
3 
4 
5 



For octet 3 'x' indicates, the value is reserved for future use. 
The list identifiers shall be ordered in ascending numerical order. 
The list identifiers are defined in clause 7.4.10.3. 



7.4.10.5.1.2 



Field 'Number' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Number 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


internal 


own 


X 


X 


X 


PIN 

protected 


3 


1" digit 


4 








2™ 


digit 















Each digit shall be out of 30H. . .39H, 23H, 2AH, 05H, 15H. 
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For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 

for future use. 

'Internal' property. The 'Internal' property is used to identify internal phone numbers. It shall be set to 1 when the 
Number represents a Terminal identity number (see clause 7.4.10.5.1.2.1). It shall be set to 1 in all entries of the internal 
names Ust. 

NOTE 1: As the call related Hsts do not include internal calls, this property is only set for the 'internal names list' 
(see clause 7.4.10.5.8). 

'Own' property. The 'Own' property is used to indicate its own entry to the PP which consults the 'internal names list". 
It shall be sent to 1 for the PP's own entry, and to for all other entries in that list. It is not used in other lists (set to in 
other lists). 

NOTE 2: The contact hst does not use the 'Number' field, but the specific 'Contact number' field (see 
clause 7.4.10.5.1.11). 

NOTE 3: 'Editable' property is set to "0" by the FP when the field is used in the 'internal names hst". 
'PEN protected' property. The 'PIN protected' property shall be set to '0', unless the field 'Number' is used: 

• as 'Dialling Prefix' field in the 'Line settings' list (see clause 7.4.11.4.4); 

• as 'Blocked number' field in the 'Line settings' list (see clause 7.4.11.4.7); 

• or as 'Terminal id number' field in the 'Internal names' list (see clauses 7.4.10.5.8 and 7.4.10.5.1.2.1 below); 

in which cases, this property can be set to '0' or '1' by the FP depending on its security policy on those hsts. See 
clause 7.4.11.1, 'PIN code' subsection, for more information. 



7.4.10.5.1.2.1 



Field 'number' for terminal identity numbers 



This field is also used for terminal identity numbers, if needed. In that case, the digits shall correspond to the decimal 
representation of the terminal identity numbers coded in IA5. For example: 

• For terminal 1, terminal identity number is 0000 OOOIB, coded value is 31H. 

• For terminal 14, terminal identity number is 0000 1 1 lOB, coded value is 3 IH 34H. 



7.4.10.5.1.3 



Field 'Name' 



Bits 



Field identifier = Name 



0/1 



0/1 



Length (L) 



editable 



1 character byte 



2^ character byte 



Octet 
1 
2 
3 
4 



Characters shall be coded as defined for UTF-8. 

NOTE: If FP supports contact list, it is reconmiended to use the name from the contact hst (if available) for 
incoming calls lists (missed and accepted) instead of the CNIP provided by the network. 

For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 
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7.4.10.5.1.4 



Field 'Date and time' 



Bits 



0/1 



0/1 



Field identifier = Date and time 



Length (L) 



editable 



Content as specified for IE «Time-DATE» octet 3 



Content as specified for IE «Time-DATE» octet 4 



Octet 
1 
2 
3 
4 
5 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Octets 4 and following are coded as specified for octets 3 and following in IE «Tinie-Date» (EN 300 175-5 [5]). 
Only 'interpretation' 000000 (=current time/date) is allowed. Any 'coding' is allowed (time or date or time & date). 

In case of multiple calls it is recommended that date and time indicate the last call. 
7.4.10.5.1.5 Field 'Read status' 



Bits 



8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 


Field identifier = Read status 


1 


0/1 


Length (L) 


2 


0/1 


editable 


unread | x | x | x 


X 


X 


3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Bit 6 of octet 3 ('unread' bit) may take the value 'unread' (1), or 'read' (0). When a new entry is added to the list, the 
'unread' bit shall be set (to 'unread' value) by the FP. 

The reset of the bit is defined by the 'read status' command, ('Mark entries request' field of the command) see 
clause 7.4.10.4.3.1. 



7.4.10.5.1.6 Field 'Line name' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Line name 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 ^' character byte 


4 


2"° character byte 


5 







For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

'PIN protected' property. The 'PIN protected' property shall be set to '0', unless the field 'Line name' is used in the 
'Line settings' list (see clause 7.4.1 1.4.1), in which case, this property can be set to '0' or '1' by the FP depending on its 
security policy for this Ust. See clause 7.4.11.1, 'PIN code' subsection, for more information. 

Characters shall be coded as defined for UTF-8. 
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7.4.10.5.1.7 Field 'Line id' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Line id 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Identifier subtype 




0/1 


Identifier value 










0/1 


Identifier value 





For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

'PEV protected' property. The 'PIN protected' property shall be set to '0', unless the field 'Line id' is used in the 'Line 
settings' list (see clause 7.4.11.4.2), in which case, this property can be set to '0' or '1' by the FP depending on its 
security policy for this hst. See clause 7.4.11.1, 'PIN code' subsection, for more information. 

The structure of the Line id field aligns to the structure of IE «CALL-INFORMATION» line identifier type (see 
EN 300 175-5 [5], clause 7.7.56). 

Identifier subtype values: 

• For aU call-related lists, the subtype shall be set to "Line identifier for external call" (call is external). 

• For the "Contact list", subtype shall be set to "Relating to" or "AU lines", depending on the contact. 

• For the "Line settings" list, and for any other list, the subtype shall be set to "Relating to". 

7.4.1 0.5.1 .8 Field 'Number of calls' 



Bits 



8 


7 1 


6 1 5 1 4 1 3 1 


2 


1 


Octet 


Field identifier = Number of calls 


1 


0/1 


Length (L) 


2 


0/1 


editable 1 


X 1 X 1 X 1 X 1 


X 


X 


3 


value 


4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Value shall be in the interval of to 255. 
7.4.10.5.1.9 Field 'Call type' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Call type 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


Missed 
call 


Accepted 
call 


Outgoing 
call 


X 


X 


X 


3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 
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7.4.10.5.1.10 



Field 'First name' 



Bits 



0/1 



0/1 



Field identifier = First name 



Length (L) 



editable 



1 cliaracter byte 



2 ° character byte 



Octet 
1 
2 
3 
4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Characters shall be coded as defined for UTF-8. 



7.4.10.5.1.11 



Field 'Contact number' 



Bits 



Field identifier = Contact number 



0/1 



0/1 



Length (L) 



editable default own Fixed mobile work 



1° ' digit 



"g^dlglt 



Octet 
1 
2 
3 
4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Field 'contact number' can be contained several times in one entry. 
A digit is out of 30H. . .39H, 23H, 2AH, 05H, 15H. 

NOTE: 'own' property is used to identify in the contact list, contact numbers belonging to the user of the system. 

This can be extended to mobile or work numbers thanks to corresponding properties. Several entries in 
the hst may have "own" property set to 1 (for example in case of several mobile numbers, multiple lines 
systems). 

7.4.10.5.1.12 Field 'Associated melody' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Associated melody 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


x 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

'PEV protected' property. The 'PIN protected' property shall be set to '0', unless the field 'Associated melody' is used 

as 'FP melody' in the 'Line settings' list (see clause 7.4. 1 1 .4.5), in which case, this property can be set to '0' or T by the 
FP depending on its security policy. See clause 7.4.1 1.1, 'PIN code' subsection, for more information. 

Value shall be in the interval of 0-255. The 'OO'H value stands for 'melody 1', 'Ol'H stands for 'melody 2', and so on. 

The length of the field shall be set to '1' when the value of the field is not defined (default melody used). 
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7.4.10.5.1.13 Field 'Call interception' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier = 


call interception 






1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Value 


4 



'PIN protected' property. The 'PIN protected' property shall be set to '0', unless the field 'Call interception' is used in 
the 'Internal names' list (see clause 7.4.10.5.8), in which case, this property can be set to '0' or '1' by the FP depending 
on its security pohcy for this list. See clause 7.4.11.1, 'PIN code' subsection, for more information. 

Value shall be BOH or 31H. BOH stands for call interception not allowed, 31H for call interception allowed. 

This field is related to the "call interception" procedure (see clause 7.4.16.2.2). When not allowed, it is forbidden for 
other PPs to intercept a call initiated by this PP. 

By default this field is set to 31 ('allowed' value). 
7.4.10.5.1.14 Proprietary fields 

Field identifiers from 81H and up to FFH are reserved for proprietary fields. Proprietary fields may be used with any list 
identifier code. This includes both, the codes defined in clause 7.4.10.3 and the proprietary list identifiers (81H to FFH). 

The format of the proprietary field shall be as follows: 



Bits 



8 


7 1 6 


1 5 1 4 1 3 1 2 1 1 


Octet 




Field identifier = 


Proprietary Field identifier (Ixxxxxxx) 


1 


0/1 


Length (L) 


2 


0/1 


Editable p 


1 P 1 P 1 P 1 P 1 P 


3 


1^" octet 


4 






n'" octet 





The use and meaning of bits p in octet 3 is up to the implementer. 
7.4.1 0.5.2 "List of supported lists" entry fields- 

This hst contains the identifiers of the lists which are supported by the FP (as some lists are optional on FP side). 



Table 64: "List of supported lists" entry fields 



Fieid identifier 


Field 


Normative action/comment 


Clause 


01 H 


List identifiers 


Single variable-length field with 
identifiers of all supported lists 


7.4.10.5.1.1 



The list identifiers are defined in clause 7.4.10.3. 

The 'List of supported Usts' refers to a list with only one entry. 

NOTE: The list identifiers are ordered in ascending numerical order (see clause 7.4.10.5.1.1). 
Field identifiers from 02H to BOH are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 
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7.4.1 0.5.3 "Missed call list" entry fields 

This list contains all the external missed calls occurring on any Une of the DECT system. 



Table 65: "Missed call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


01H 


Number 


Number of the calling party 


7.4.10.5.1.2 


02H 


Name 


Name of the calling party 


7.4.10.5.1.3 


03H 


Date and Time 


Date and Time of the missed call 


7.4.10.5.1.4 


04H 


Read status 


Indicates whether entry is shown first 

time 


7.4.10.5.1.5 


05H 


Line name 


Name of line on which the call was 
received 


7.4.10.5.1.6 


06H 


Une id 


Id of line on which the call was 

received 


7.4.10.5.1.7 


07H 


Number of calls 


Indicates amount of missed calls 
from this calling party 


7.4.10.5.1.8 



'Line id' field. The FP shall implement the 'Line id' and 'Line name' fields in the list even if the multiple line feature 
[NGLN14] is not implemented in the FP (systems with only 1 line). 

'Number of calls' field. Successive unsuccessful calls from the same remote party (and on the same line), that are close 
enough in time to one another, may be accounted for in a single 'missed call Ust' entry. In that case the 'Number of 
calls'field shall hold the number of these calls; otherwise it shall hold the value '1'. 

When a new missed call occurs from a party forwhich an entry already exists in the missed calls list, the FP shall 
implement one of the two following merging strategies concerning the 'number of calls' field: 

• Strategy 1: no merging of missed calls in the list. When missed call occurs, a new entry shall be created by the 
FP with 'number of calls' field set to 1 ('ReadStatus' will be set to 'unread' as this is a new entry). 

• Strategy 2: merging of missed calls from the same party into one list entry. When missed call occurs, the FP 
shall modify the existing entry and shall follow the following rules: 

The FP shall increment the 'number of calls' field (value greater than 1). 

The FP may update the 'Date and Time' field, for example, with the date and time of the last arrived in 
time call from this remote party. 

The FP shall set the '"Read status' to 'unread' value. 

In any of these cases. The FP use the appropriate notifications to PPs as defined in clauses 7.4.10.2 (List change 
notification clause) and 7.4.1.3 (Missed call notification). 

PP shall support both strategies. 

NOTE 1 : In the case of merging strategy, the total number of entries in the list remains unchanged in the 
notification. 

NOTE 2: If one of the PPs was reading the missed calls list when the incoming call arrives the PP may have to 
restart the session to have a missed call list status consistent with the reality. Especially when 
implementing some merging. Sorting of the list and read status could have changed in the FP after 
reading in the PP. 

NOTE 3: A FP may decide to implement merging of entries with recent entries and no merging if the existing entry 
is very old. For example merging only with the most recent entry of the missed calls list (Mix of strategies 
on a call by call basis). 

Field identifiers from 08H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 
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7.4.1 0.5.4 "Outgoing call list" entry fields 

This list contains all external outgoing calls occurring on any line of the DECT system. 



Table 66: "Outgoing call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


01H 


Number 


Number of the called party 


7.4.10.5.1.2 


02H 


Name 


Name of called party 


7.4.10.5.1.3 


03H 


Date and Time 


Date and Time of the call 


7.4.10.5.1.4 


04H 


Line name 


Indicates name of line used for the call 


7.4.10.5.1.6 


05H 


Line id 


Id of line line used for the call 


7.4.10.5.1.7 



'Line id' field. The FP shall implement the 'Line id' and 'Line name' fields in the list even if the multiple Une feature 
[NG1.N14] is not implemented in the FP (systems with only 1 Une). 

Field identifiers from 06H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.1 0.5.5 "Incoming accepted call list" entry fields 

This list contains all the accepted external incoming calls occurring on any line of the DECT system. 



Table 67: "Incoming accepted call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


01 H 


Number 


Number of the calling party 


7.4.10.5.1.2 


02H 


Name 


Name of calling party 


7.4.10.5.1.3 


03H 


Date and Time 


Date and Time of the call 


7.4.10.5.1.4 


04H 


Line name 


Name of line on which the call was 
received 


7.4.10.5.1.6 


05H 


Line id 


Id of line line used for the call 


7.4.10.5.1.7 



'Line id field'. The FP shall implement the Line id' and 'Line name' fields in the list even if the multiple line feature 
[NG1.N14] is not implemented in the FP (systems with only 1 Une). 

Field identifiers from 06H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.10.5.6 "All call list" entry fields 

This list contains all external calls (missed, outgoing, incoming accepted) occurring on any line of the DECT system. 



Table 68: "All call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


01 H 


Call type 


Coding of the list: 

missed / accepted / outgoing 


7.4.10.5.1.9 


02H 


Number 


Number of the calling/called party 


7.4.10.5.1.2 


03H 


Name 


Name of calling/called party 


7.4.10.5.1.3 


04H 


Date and Time 


Date and Time of the missed call 


7.4.10.5.1.4 


05H 


Line name 


Name of line on which the call was 
received/passed 


7.4.10.5.1.6 


06H 


Line id 


Id of line line used for the call 


7.4.10.5.1.7 



'Line id field'. The FP shall implement the 'Line id' and 'Line name' fields in the list even if the multiple Une feature 
[NG1.N14] is not implemented in the FP (systems with only 1 line). 
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Field identifiers from 07H to 80H are reserved for fiirther standardization and shall not be used. 

Field identifiers from 8 IH to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.1 0.5.7 "Contact list" entry fields 

This Ust contains the contact Ust (or phone book) for the complete DECT system. 



Table 69: "Contact list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


01 H 


Name 


Name of the contact (last name) 


7.4.10.5.1.3 


02H 


First name 


First name of the contact 


7.4.10.5.1.10 


03H 


Contact number 


Number of the contact 


7.4.10.5.1.11 


04H 


Associated melody 


Ringing melody used for the contact 


7.4.10.5.1.12 


05H 


Line id 


Id of line used for the call 


7.4.10.5.1.7 



'Associated melody'. The 'Associated melody' defines the melody which is used when an incoming call is received 
from the number in the 'Contact number' field. It allows to select the melody on FP and potentially on PP side. 

The support of this field by the FP is optional. The PP may know the presence of the field via the 'query supported entry 
field' conmiand. The FP may implement this field in two cases : 

• Use case 1: when FP has configurable ringing capabilities. 

• Use case 2: in order to personnahze the melodies used on PP side but based on the contact list in the FP. This 
use case may come in addition to use case 1. 

When not implemented, the field is not included in any entry of the list. 

The support of this field by the PP is also optional. 

Use of the field by the FP: if the FP has ringing capabilities, the FP may use it to select the melody to be played on FP 
side. This melody overrules the 'FP melody' field in the Line settings list. In other words, the FP plays this melody 
instead of the default melody defined for this hne. The volume to be used by the FP shall be the volume defined in the 
corresponding line setting list entry 'FP volume' field. 

If the FP uses the field 'associated melody' to select the FP melody it should also implement 'FP melody' and 'FP 
volume' fields in the Une settings list. 

Use of the field by the PP: ?his field may also be used by the FP to send ring pattern in «SIGNAL» IE to the PP. In 
that case, 'OO'H value stands for 'Alerting on - pattern 0', 'Ol'H stands for 'Alerting on - pattern 1', and so on. In this case, 
only values up to '07'H may be transmitted to the PP. 

This field may also be set to 'undefined value' (see clause 7.4.10.5.1.12). In this case, the FP shall use its default melody 
(optionnally defined in the line settings list). 

'Line id field'. The FP shall implement the 'Line id' field in the list even if the multiple line feature [NG1.N14] is not 
implemented in the FP (systems with only 1 line). 

If the entry is related to all hues in the system, the field 'Line id/subtype' shall be set to "All lines". 

'Contact number field'. The FP shall implement at least two contact number fields per entry in the contact list. The PP 
shall make accessible to the user at least one contact number per entry of the contact list. (However, the PP shall save 
the same number of 'contact number' in the 'save entry'command as received in the 'edit confirm' command (see 'save 
entry conmiand' clause 7.4.10.4.5.1)). PP may know the number of 'contact number' supported by the FP via the 'query 
supported entry fields' command. 

NOTE : From implementation point of view, three contact numbers per entry are recommended on FP side. Each 
contact number may be of any type (fixed, mobile or work). 

Field identifiers from 06H to 80H are reserved for further standardization and shall not be used. 
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Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.1 0.5.8 "Internal names list" entry fields 

This list contains the names of registered PPs of the complete DECT system. 



Table 70: "Internal names list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


01H 


Number 


Terminal identity number 


7.4.10.5.1.2 (see 
note 1 ) 


02H 


Name 


Name of the internal party 


7.4.10.5.1.3 


03H 


Call 

interception 


Call interception allowed or not 


7.4.10.5.1.13 (see 
note 2) 


NOTE 1 : Clause 7.4.10.5.1.2.1 specifies the coding of terminal identity numbers. 
NOTE 2: 'Call interception' field is relevant for each PP (especially headset PPs) 
(see clause 7.4.16). 



One and only one entry per terminal identity number shall exist in the "Internal names" list. A PP is not allowed to 
modify the "number" field using edit and save commands'. If a PP attempts to do so, the FP shall reject it after the save 
with negative acknowledgement and reject reason "procedure not allowed" (as defined in clause 7.4.10.4.5.2). 

When a PP registers to the FP, the FP shall automatically add a corresponding entry in the internal names list (see 
clause 7.4.11.2) with: 

• an assigned "number" (terminal identity number). Editable property bit of the field set to OB (field not 
editable); 

• a default name. (For example "DECT n" where n stands for the terminal identity number in decimal 
representation); 

• the 'Call interception' field set to 'allowed' as default value. 

User may later set the value of 'Call interception' field to 'Not allowed' if he wants to prevent any call on this specific PP 
from being intercepted. 

When the PP is consulting the 'internal names list', the FP shall dynamically set to 1 the 'Own' property of the 'Number' 
field of the entry corresponding to this PP. This mechanism allows the PP to avoid displaying its own entry. For 
example, if user initiates an internal call from PPl and PPl displays the internal names Ust, PPl has a way to display 
only PP2, PPS . . .PPn (display of possible remote parties which does not include PPl itself). 

Field identifiers from 04H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.1 0.5.9 "DECT system settings list" entry fields 

See clause 7.4.1 1.3. 

7.4.1 0.5.1 "Line settings list" entry fields 
See clause 7.4.11.4. 
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7.4.1 0.5.1 1 "All incoming calls list" entry fields 

This list contains all the incoming calls, including both accepted external incoming calls and missed external calls, 
occurring on any Une of the DECT system. "All incoming calls list" entry fields are the same as "Missed call list" entry 
fields, see clause 7.4.10.5.3. 

For an incoming accepted call entry in the "All incoming calls list": 

• the 'Read status' field value shall be set to '0'; 

• the 'Number of calls' field value shall be set to 1 . 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.1 0.6 List access service call and interactions with voice calls 

This section describes list access setup general considerations, and the interactions between the list access service and a 
voice call using the same DECT NWK layer C/O service instance (the same "call" from DECT NWK layer point of 
view). 

A list access session can be started by a PP either in idle mode or already involved in a call. For this version of the 
standard, the List access service shall only use the Cs channel. 

As the Cp channel shall not be used for this version of the standard, the FP capability bit a26 shall be reset. 
The following use cases are covered in this version of the present document: 

• The PP in idle mode starts a list access session on Cs channel. 

• The PP in idle mode starts a list access session on Cs channel and then places a voice call. The list access 
session, if not closed, continues on Cs channel. 

• The PP in idle mode starts a list access session on Cs channel and then receives (and accepts) a voice call 
during the list access session. The list access session, if not closed, continues on Cs channel. 

• The PP starts a list access session during a voice call on Cs channel. 
As a consequence: 

• PP and FP shall support "List access setup" as described in clause 7.4.10.6.1. 

• PP and FP shall support "List access with possible first voice call initiation" as described in clause 7.4.10.6.2. 

• PP and FP shall support "Incoming voice call during existing list access session" as described in 
clause 7.4.10.6.3. 

• PP and FP shall support "List access during existing voice call with possible second call initiation" as 
described in clause 7.4.10.6.4. 

• The PP and FP shall support procedure "Switching between LiA session and voice call" of clause 7.4.10.6.5. 

• The PP and FP shall support procedure "Returning to LiA session after voice call termination" of 
clause 7.4.10.6.6. 

In addition, the FP shall temporarily restrict access to some of the lists during a voice call (DECT system, line setting 
and internal names lists), in order to ensure the integrity of the system while it is used. In this case, FP shall prevent 
from modifying the requested Ust entry (negative acknowledgement with reject reason 'temporarily not possible') until 
the voice call is released. In other words, FP shall temporarily prevent "edit entry", "save entry" and "delete entry" 
commands for some entries, as well as "delete list" command. PP shall support such answers when requesting those 
connmands on any of the 3 lists. 
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7.4.1 0.6.1 List access setup 

The list access service can be used, and all lists may be accessed, whatever the call class of the underlying call. In other 
words, the <call class> field value of the «basic service» I.E. used at call setup may be 'Normal call setup', 'Internal 
call setup', or 'LiA service call setup' defined in EN 300 175-5 [5], clause 7.6.4. 

However, the following rules shall be fulfilled: 

1) If the PP was idle when starting a hst access session, it shall use call class 'LiA service call setup', the <basic 
service> "wideband speech default" and the default setup attributes defined in clause E.2 of EN 300 175-5 [5]) 
because this service call may end up into a voice call. 

2) If the PP was already involved in a voice call (internal or external) when starting a list access session, it shall 
continue using the same call and call class. 

In case 1 and 2, no call id shall be assigned for the LiA service call. 

In case 1, the LiA service call is not connected ({CC-CALL PROC} is used, but no {CC-CONNECT} is used). 
{CC-CONNECT} is only used if a voice call is subsequently connected. The LiA service call shall be connected later 
only when a voice call is processed. 

If the PP was idle when starting a list access session, it shall initiate a first call using {CC-CETUP} and call class 'LiA 
service call setup': 

• the Cs channel shall be used; 

• the FP shall immediately answer with a {CC-CALL-PROC}, without call status nor call id. No call id shall be 
assigned to the LiA service call; 

• the 100 second timer F<CC.04> / P<CC.04> defined in EN 300 175-5 [5], clauses 9.3.1.5 and 9.3.1.6 for a 
{CC-CALL PROC} message shall not apply in this case on PP side, nor on FP side. 

Inactivity timer: 

The PP shall implement an inactivity timer mechanism intended for not leaving list access sessions opened for ever on 
FP side. 

If the PP is not involved in a call and no activity is detected on PP side during a certain time on the list access, once Ust 
access session is started, PP shall immediately release the call by sending a {CC-RELEASE} and stop the timer. 

If the PP becomes additionnaly involved in a voice call, the inactivity timer may be stopped. It shall be re-started after 
the end of the voice call if the Ust acess is still opened. 

NOTE 1 : A possible implementation is that the PP re-starts the timer, each time a list access command is sent by 
the PP and each time user activity is ongoing in the list on PP side (for example up/down scrolUng in a 
hst without any hst access command sending). 

NOTE 2: Value of the timer is left free to implementation. However it is recommended that the inactivity timer 
value is no more than 300 seconds. 



7.4.1 0.6.2 List access witli possible first voice call initiation 

The provisions of 7.4.10.6.1 shall be respected. Additionally, if the list access session is intended to establish a first 
voice call: 

• The PP shall initiate a pseudo outgoing parallel call by using the "Outgoing parallel caU initiation" procedure 
(see clause 7.4.3.5.1) with the following modifications: 

The PP is using the number (external or internal) read from the hst access session, sent in a single 
CC-INFO message ('1C15'H / '17'H + called number) along with a line identifier. 

• The PP may close the list access session, by using the 'End session command' (see clause 7.4.10.4.1.3), after 
the CC-INFO has been sent to make sure the FP does not release the hnk in the meantime. 
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NOTE 1 : Actually the PP is using the outgoing parallel call initiation procedure, in order to establish a first call, 
because the link was already established when starting the list access session. 

NOTE 2: There is at this point an implicit change of call class, from 'LiA service call setup' to 'Normal call setup', 
or to 'Internal call setup'. 

• The FP shall immediately answer with a CC-CONNECT, along with a default codec, in order to connect the 
U-plane (active audio path). This allows to handle the rest of the voice call as a pseudo outgoing parallel call. 
Neither call id nor call status nor line id are sent along with CC-CONNECT, as they are sent in subsequent 
CC-INFO as for regular outgoing parallel call. 

• The FP shall then send the appropriate call status (most likely 'CS call proc') in a subsequent CC-INFO 
message, with the newly assigned call id. 

• The codec negotiation shall be carried out as for a normal first outgoing voice call, (optional 
«C0DEC-L1ST» sent in {CC-SETUP}, mandatory «CODEC-LlST» with a single codec sent (once) by 
the other side with «PROGRESS-INDICATOR» at the latest (if used), or in {CC-CONNECT}. See 

TS 102 527-1 [21], clause 7.3.3). This means that a default codec is chosen by the FP at latest in 
CC-CONNECT. 

• If the default codec is not suitable for the voice call, a codec switching may be initiated by the FP. In this case, 
this will very probably be performed between the outgoing parallel call initiation by the PP, and the sending of 
the 'CS call connect' call status by the FP. 

• If the PP left the list access session open, the FP and PP shall comply with procedure "Switching between LiA 
session and voice call" of clause 7.4.10.6.5. 

• In order to return to the LiA session at the end of the voice call if it remained open, the PP and FP shall use the 
procedure "Returning to LiA session after voice call termination" of clause 7.4.10.6.6. 
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PP 



FP 



CC-SETUP 



« BASIC SERVICE, < Call class = 'LiA service call' > 

» 

CC-CALL-PROC 



NO «CALL-INFORMATION» here, because 

no call id is used for a list access service call 
no 'CS call proc' call status either 



LiA session started 
Number found. 



Pseudo outgoing parallel call Initiation used for 
first call 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1 CI 5/1 7'H + 'calle i number' > 



PP possibly ends tine LiA session 



CC-CONNECT 



If still open, LiA session continues on Cs channel 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call proc' 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call alerting' > 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call connect' > 



Service call: 
No call id used 



No CC-SETUP-ACK 



no call liold in 



U-plane open 
(local connection) 



Call id 

assignement 



networl< message 
'peer party is alerting' 



network message 
'peer party is active' 



Figure 56: List access withi possible first voice call initiation 

NOTE 3: For concisness of the figure, neither line identifier nor codec negotiation are represented. 
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7.4.1 0.6.3 Incoming first voice call during existing list access session 

If an incoming voice call is received when the PP is involved in a list access session: 

• The FP shall first answer with a CC-CONNECT along with a default codec, in order to connect the U-plane 
(active audio path). This allows to handle the incoming voice call as a pseudo call waiting. Neither call id nor 
call status nor hne id are sent along with CC-CONNECT, as they are sent in subsequent CC-INFO as for 
regular call waiting (and actually for a first incoming call, the CC-CONNECT would be in the other direction). 

• The FP shall present a pseudo call waiting to the PP by using the "Call waiting indication" procedure (see 
clause 7.4.3.5.2) in order to present the incoming call to the PP (including the call id for this call). 

NOTE 1: The call waiting indication procedure is used here for presenting a first call, because the link was already 
established when starting the list access session. 

• The PP shall present the incoming call to the user. For example by ringing as for an incoming first call. 

• The FP shall also present the incoming call as a first call to any other idle PP. 

• If the user accepts the call, the PP may close the hst access session, prior to sending the call waiting 
acceptation, by using the End session command' (see clause 7.4.10.4.1.3). 

• The PP and FP shall support all call waiting related parallel call procedures defined in clause 7.4.3.5 in order 
to handle the pseudo call waiting (including the handling of call id, call statuses, exception cases, etc.). More 
specifically: 

If the PP wishes to answer the incoming call, it shall use the "Call waiting acceptation" procedure (see 
clause 7.4.3.5.6), with the following modifications: 

■ The FP shall send the 'CS call connect' call status (with the call id) in a subsequent CC-INFO 
message. 

■ As the procedure is used here for a first call, the FP shall not send back any 'CS call hold' call status 
to the PP (no call to be put on hold). 

If the PP wishes to reject the incoming call, it shall use the "Call waiting rejection" procedure (see 
clause 7.4.3.5.7), with no modification. 

■ The handhng is similar to clause 7.4.6.6 "returning to LiA session after voice call termination" 
(case where PP hangs up the call). FP shall mute the audio. 

NOTE 2: There is at this point an implicit change of the call class, from 'LiA service call setup' to 'Normal call 
setup', or to 'Internal call setup'. 

• The codec negotiation shall be carried out as for a first outgoing voice call (although we are in an incoming 
voice call scenario) : optional «CODEC-LlST» sent in {CC-SETUP}, mandatory «CODEC-LlST» with 
a single codec sent (once) by the other side with «PROGRESS-lNDlCATOR» at the latest (if used), or in 
{CC-CONNECT}. See TS 102 527-1 [21], clause 7.3.3). This means that a default codec is chosen by the FP 
at latest in CC-CONNECT. 

• If the default codec is not suitable for the voice call, a codec switching may be initiated by the FP. In this case 
this will very probably be performed between the call waiting acceptation by the PP and the sending of the 'CS 
call connect' call status by the FP. 

• If the PP left the list access session open, the FP and PP shall continue using the Cs channel for the hst access 
session. 

• In order to return to the LiA session at the end of the voice call if it remained open, the PP and FP shall use 
procedure "Returning to LiA session after voice call termination" of clause 7.4.10.6.6. 
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PP 



CC-SETUP 



FP 
-> 



« BASIC SERVICE, < Call class = 'LiA service call' > » 
GC-CALL-PROG 



NO «CALL-INFORMATION» here, because 

no call Id Is used for a list access service call 
no 'CS call proc' call status either 



Service call: 
No call id used 



No CC-SETUP-ACK 



LiA session started 



U-plane open 
(local connection) 



PP presents 
call to the 



If incoming call 
external 



LiA session 
termination 
may not be 
user intiated 
(PP 

implementation 



GG-CONNECT 



Pseudo call waiting used for first call 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 'calling number' > » 
« CALL-INFORMATION, 

< id type = 'Line id', subtype = 'external call', value = 'waiting 
id'> 

< id type/subtype = 'Call identifier', value = 'waiting call id' 

< id type/subtype = 'Call status', value = 'CS call setup' > 



PP possibly ends ttie LiA session 



call waiting acceptation 

CC-INFO 



« MULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORMATION, 'Call identifier' = 'waiting call id' = 



If still open, LiA session continues on Gs channel 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' 

< id type/subtype = 'Call status', value = 'CS call connect' 



Incoming voice call 



If required by the 
'Tones provision' 



call line 
02'H> 



In multiple call mode, 
other handsets stop 
ringing or receiving 
the CW indication 
'02'H > » 



networl< message 
'peer party is active' 



'02'H > End to end 
connection for 
the voice call 



Figure 57: Incoming first voice call during existing LiA session, connected in the same call 

NOTE 3: For concisness of the figure neither hne identifier nor codec negotiation are represented. 



7.4.10.6.4 



List access during existing voice call with possible second call initiation 



This procedure illustrates the use of a regular parallel call initiation in case a second call is setup when a list access 
session and a voice call were already established in parallel. 

NOTE: This is in contrast to clause 7.4.10.6.2 which uses a pseudo outgoing parallel call initiation. 

If the PP was already involved in a voice call (internal or external) when starting a list access session (e.g. contacts list 
consultation for a parallel call initiation use case): 

• the PP shall comply with procedure "Switching between LiA session and voice call" of clause 7.4.10.6.5 when 
starting the LiA session; 
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• the FP shall not assign any call id for the list access session. 

Additionally, if the Hst access session is intended to establish a parallel voice call, and when the number to be called 
has been found: 

• the PP shall use procedure "Switching between LiA session and voice call" of clause 7.4.10.6.5, in order to 
handle the switching from the LiA session to the first active voice call; 

• the PP shall use the "Outgoing parallel call initiation" procedure (see clause 7.4.3.5. 1) using the number 
(external or internal) read from the list access session; 

• the PP may close the list access session, by using the 'End session command' (see clause 7.4.10.4.1.3)., after 
the CC-INFO (initiating the parallel call) has been sent to make sure the FP does not release the link in the 
meantime. 
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PP 



FP 




Optionally 
put the 
ongoing 
call on- 
hold 



Outgoing 
parallel call 
initiation with 
number 



If not 
already 
done 
before 



Ongoing call (external or internal, call 




CC-INFO 



« MULTI-KEYPAD, info = '1C 41'H » 

« CALL-INFORMATION, 'targeted callid' = '01 'H > » 

CC-INFO 



« CALL-INFORMATION, 'targeted call id' = '01 'H > 
< 'Call status' 'CS call hold' > » 



LiA session started / Number found. 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1 5/1 7'H -i- 'called nu nber' 



PP possibly ends the LiA session 



CC-INFO 

|. 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 
_< id type/subtype = 'Call status ', value = 'CS call hold' 

CC-INFO 



As described 
in 7.4.10.6.5 



Regular second call 
> 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call proc' > 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call 
alerting' > » 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call 
connect' > » 



Call id 

assignement 
here 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Figure 58: List access during existing voice caii with second cail initiation 
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7.4.1 0.6.5 Switching between LiA session and voice call 

This procedure is used when a list access session is open on Cs channel and a voice call is active in parallel. 
The following rules shall be appUed: 

• if the voice call is started while a list access session was already open, the FP and PP shall continue using the 
Cs channel for the Ust access session. The voice call initiation (incoming or outgoing) is described in other 
procedures; 

• the list may be accessed any time during the voice call, through IWU to IWU messages; 

• the U-plane always remains connected for the duration of the call; 

• if a list access session is started while a voice call is active, the voice call may be put on hold; otherwise, the 
voice path with the remote party remains open. 

NOTE: If the LiA session is open for starting a second call (contact list consultation), putting the active call 
on-hold only anticipates what will happen when the second call will be initiated. 

7.4.1 0.6.6 Returning to LiA session after voice call termination 

This procedure is applicable only if a LiA session is still opened at the time a voice call is terminated. 

NOTE : For example this procedure is not applicable if the PP decides to close the LiA session before hanging up 
the voice call. A simple CC-RELEASE can be used in this case. 

There are two cases of voice call termination while leaving the LiA open: 

• If the remote party hangs up, the FP shall release the call using 'CS idle' as defined in clause 7.4.3.5.4, but shall 
not release the link. 

• Additionnally, the PP may terminate the voice call and leave the Ust access session active by using a call 
release request as defined in clause 7.4.3.5.4. In that case, the PP shall re-start the inactivity timer when 
sending the call release request. 

In both cases, when the voice call is terminated: 

• the FP shall maintain the Unk until the list access session is closed; 

• the U-plane shall remain open; 

• and the audio shall be muted (FP shall send mute pattern as defined in 102 527-1 [21], annex B and ignores the 
audio received from the PP). 



ETSI 



187 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



PP FP 





^.-■■^ Ongoing call (external or internal, call^^-\ 

^ ^ 






If the PP 
hangs up 


Call release request 

CC-INFO 




Absent if the 
remote party 
hangs up 


► 

« MULTI-KEYPAD, info = '1C 33'H » 

« CALL-INFORMATION, 'targeted call id' = '01 'H > » 






CC-INFO 

< 






« GALL-INFORMATION, 'targeted call id' = '01 'H > 
< id type/subtype = 'Call status', value = 'CS idle' > 

» 




Audio 
^ muted 


IWU to IWU session continued 







Figure 59: Returning to LiA session after voice call termination 



7.4.1 0.7 Generic sequence charts for list access 

See clause B.3 for examples of sequence charts for list access. 

7.4.1 0.8 Use case examples for list access 

See clause C.5, C.6, C.7 and C.8 for examples of use cases for list access. 

7.4.1 1 DECT system and line settings 

7.4.1 1 .1 DECT system and line settings considerations 

DECT system and line settings shall use the "List access service" procedures with the following additional 
requirements. 

DECT system settings consist of a set of settings that are valid for the complete DECT system, i.e. valid for all 
registered PPs independently of line / multiple line concepts. They are stored in the FP as a unique list with only one 
entry in the list. Each setting is a field of this entry. 

Line settings consist of a set of settings that are valid for one hne of the DECT system, i.e. valid for all registered PPs 
attached to this Une. They are stored in the FP as a unique Ust with one entry per line in the list. Each setting is a iield of 
this entry. Even if the DECT system does not implement multiple line features, the FP and PP shall support line settings 
with only one entry: the settings for the only line supported by the system. 

Sorting of the lists: 

No sorting is defined for the "DECT system settings" Ust, as it contains only one entry. 

The "Line settings" Ust is sorted by ascending line id number. 

Commands: 

AU the "List access service" feature connmands shaU be supported for the "DECT system and line settings" feature, 
except for: 

• The "delete entry" command is not aUowed for the "DECT system settings" list. 
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The "delete list" command is not allowed for the "DECT system settings" Ust, nor for the "Line settings" list. 

These commands shall not be invoked by any PP and shall be answered with negative acknowledgement from the FP 
with reject reason "procedure not allowed" (see clause 7.4. 10.4.9). 

Saving a new hue setting entry or deleting a hue setting entry is allowed (when creating or removing a hne for the 
DECT system). Please refer to clause 7.4.11.2 "Interactions between registration, attachment of handsets and lists" for 
impacts. 

Only one entry per line identifier shall exist in the "Line settings" Ust. In other words, two distinct entries shall never 
have the same line id (see clause 7.4.11.3 for details). 

Settings (fields of DECT system and line settings lists): 

Some DECT system or line settings are mandatory and shall be supported both by the FP and the PP. Please refer to 
clause 6.10, table 9 for status of each setting. When a setting is mandatory in the table, the related field is mandatory 
and shall be implemented in the PP and the FP. 

The PP may use the "Query supported entry fields" procedure (see clause 7.4.10.4.2) to know which settings (fields) are 
supported by the FP. The FP shall answer with mandatory and optional settings implemented in the FP. This way, the 
PP will be able to give proper indication to the user (when accessing the settings menus for example). 

All settings shall have default value set when product is manufactured. Some of these settings may be reset to default 
value with the "Base reset" setting. Please refer to tables 71 and 72 for details. 

For some specific settings, a PP may request the reset of the setting/field by setting the field length to 1 (only octet 3 
available in entry field). The field itself is not removed from the FP list entry. For each field this possibihty is described 
in clause 7. 4. 11. 4. It has to be noted that resetting some fields in some hsts can be dangerous and should be carefully 
controlled by the PP (FP IP address for example). 

EXAMPLE: If no dialling prefix is set, the length of this field shall be one. 

The PP may modify 1 to n setting(s) by using an "Edit entry" command with the following parameters: (session 
identifier, entry identifier=l, 1 to n field identifiers). 

PIN code: 

For security reasons, the PIN code shall never be sent over the air on a non ciphered link. Moreover, the FP shall 
prevent a non-allowed PP to save a new PIN code: 

The PIN code is used-among other uses-to protect the following lists against unauthorised modifications of some or all 
of their fields: 

• 'DECT system settings' list (including the PIN code itself). 

• 'Line settings' list. 

• 'Internal names' list. 

The reading of fields is not protected. The PIN code itself ('DECT system settings' list) is not readable, even after 
successful PIN authentication (an invalid value is returned in any case). 

For each of the hsts above, the subset of fields that require protection is left free to the implementer. If the FP requires 
'PIN protection' for a field, it shall set to '1' the 'PIN protected' property of that field when sending it to the PP. 

However, the FP shall always PIN protect the 'New PIN code' field of the 'DECT system settings' list. 

For the PIN code value, two distinct fields are defined in the 'DECT system settings' hst, which are both protected 
against reading: 

• the 'Current PIN code' field is only used to check the PIN code entered by the user. As it is not directly 
modifiable, it is not considered as 'PIN protected'; 

• the 'New PIN code' field is used to modify the PIN code and is therefore always 'PIN protected'. 
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At least when accessing either the 'Current PIN code' or the 'New PIN code' setting of the "DECT system settings" Ust, 
with any command, the connection shall be ciphered; i.e.: 

• for "Read entries confirm", "Search entries confirm", "Edit entry confirm", "Save entry" and "Save entry 
confirm" conamands that includes the PIN code fields 'Current PIN code' and 'New PIN code' in data packets, 
the DECT link shall be ciphered prior to the command; 

• if this not the case, the FP shall answer with a negative acknowledgement, with reject reason = "procedure not 
allowed" (see clause 7.4.10.4.9). 

For the 'Current PIN code' and 'New PIN code' fields of the 'DECT system settmgs' list, and after any 'Edit 
entry' or 'Read entry' command on any of these two fields: 

• the FP shall answer with the invalid value 'FFFFFFFF'H, instead of the real value of the field. 

For any 'PIN protected' field of the 'DECT system setting', 'Line setting', or 'Internal names' lists (including 

the 'New PIN code' field of the 'DECT system settings' list): 

• before saving a new value for that PIN protected field, the PP shall: 

open a (parallel) list access session with the 'DECT system setting' list, if such a session does not already 
exist (i.e. if the field to protect is not from that list), 

perform the 'Edit entry' and 'Save entry' commands on the 'Current PIN Code' field of the 'DECT system 
setting' list: 

■ After the 'Save Entry' command, the FP shall compare the received value with the stored value of 
the field, but the FP shall not modify this stored value. 

■ If the entered PIN code is correct (the 'Save Entry' command was successful), the FP shall allow the 
PP to save a new value for the PIN protected field in the same list access session via the "Save 

entry" command. 

■ If the entered PIN code is incorrect, the FP shall answer with a negative acknowledgement with 
reject reason 'incorrect PIN'. 

• when using a 'Save entry' command for modifying the value of that PIN protected field: 

In case the field to be modified is the 'New PIN code' field, the new value shall be stored in both the 
'Current PIN code' and 'New PIN code' fields. 

As soon as there as been a 'DECT system settings' list access session with correct PIN authentication in 
the current call all subsequent modifications on any of the three lists are allowed during the same call. 

In all cases, if the 'Save entry' command occurs at a point in time where, in the same call: 

■ there has been no successful save of the 'Current PIN code' field before; or 

■ there has been an unsuccessful save of that field before; 

■ the FP shall answer with a negative acknowledgement with reject reason 'PIN code required'. 

Access to the "DECT system settings" menu on the PP may be conditioned to prior PIN code keyboarding and may be 
completely in ciphered mode. This is left free to the implementer. 

See clauses C.7.2, C.7.4 and C.8.4 for examples of use cases related to PIN code and PIN code protected fields. 
Initial value: 

The "DECT system settings" list unique entry is at position index 1 in the DECT system list. 
First "Line settings" list entry is at position index 1 in the line settings list. 
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7.4.1 1 .2 Interactions between registration, attacliments of liandsets and lists 

"Internal names" list fully reflects the registered PPs. At registration of a handset, the FP shall add a new entry in the 
"Internal names" list with a default name. " 

With a "mono-line" FP, the FP shall automatically attach the PP to the unique line, "Attached handsets" setting in the 
line setting list entry shall also automatically be updated by the FP with corresponding bit set. 

With a "multiple lines" FP (FP connected to several lines and implementing the multiple Unes feature [NG1.N.14], the 
FP should automatically attach the registered PP to at least one line (i.e. update "Attached handsets" setting in at least 
one entry of the line settings list). This default attachement may be later updated by the PP or done on FP side 
(e.g. through a web interface). Other implementations are allowed (i.e. attaching the PP to all lines by default). 

Except during a temporary period (i.e. as result of modifications/creations/deletions of lines), a registered handset shall 
always be attached to at least one line: the PP shall appear at least in one "Attached handset" field of one line setting. It 
may appear in several line settings if it is attached to several lines. 

Deleting an entry in the "Internal names" list shall result in the de-registration of the corresponding handset from the 
system using the "Terminating access rights FT initiated" procedure. This procedure shall be performed as defined in 
EN 300 444 [12], clause 8.31. The "Attached handsets" field in the line setting(s) list shall also be automatically 
updated by the FP. In case the corresponding handset is out of range when the 'delete entry' request is processed, the FP 
shall delay the "Terminating access rights FT initiated" procedure until the PP goes back in range. The PP shall be 
however immediately removed from the 'internal names list' and from the 'Attached handset' fields. 

Deleting one entry (one line) of the line settings list shall result in the de-attachment of the corresponding handsets from 
the line. If, as a consequence of a "delete entry" command on the line settings list, a handset is no longer attached to any 
line anymore, it shall however remain registered and available in the "Internal names" list. This handset is no longer 
reachable from external lines. This temporary state may arise especially when removing and creating new lines. 

NOTE 1 : This mechanism makes it possible to register/unregister any handset to/from the DECT system, and to 
attach/detach it to/from a line in two separate steps. 

NOTE 2: As specified in the "Multiple lines" feature NG1.N.14, attachment may be PP-managed (for example, the 
user chooses the line at registration) or FP-managed (for example, the handset is attached by default to a 
hne). 

A FP may decide not to implement the 'delete entry' and 'save entry' (for creating a new entry) commands for the line 
settings list. If the FP does not implement those commands it shall however answer those conmiands with negative 
acknowledgement reject reason 'procedure not allowed'. The PP shall support such answers. 

NOTE 3: This may be the case for a FP using a web interface to configure the line settings. Or for a FP supporting 
some PSTN lines (as the FP is designed by default with a given number of PSTN line cormectors). 

NOTE 4: The 'save entry' command used for modifying an existing entry remains possible on FP side. 

If the "Base reset" influences the "Internal names" list or the "Line settings" list attached handsets, the corresponding 
handsets de-attachments and un-registrations shall be correctly handled. 
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7.4. 1 1 .3 DECT system settings list 

The following entry fields are defined for the (singular) DECT system list entry. 

Table 71 : Entry fields for the (singular) DECT system list entry 



Field 


Field 


Default 


Base 


Normative action/comment 


Clause 


identifier 




value 


reset 
impacted 






01 H 


Current PIN code 


YES/MD 


MD 


Before a PIN protected field (i.e.: a 
new PIN code) can be saved an 
edit/save of the current PIN code is 
required 


7.4.11.3.1 


02H 


Clock master 


MD 


MD 


Defines tlie entity whicli sets date an 
time for the DECT system (PP or FP) 


7.4.11.3.2 


03H 


Base reset 


YES 


YES 


Sets settings back to default factory 
values 


7.4.11.3.3 


04H 


FP IP address / type 


IVID 


MD 


DHCP or static 


7.4.11.3.4 


05H 


FP IP address / value 


MD 


MD 


Editable only for static IP address 


7.4.11.3.5 


06H 


FP IP address / subnet mask 


MD 


MD 


Editable only for static IP address 


7.4.11.3.6 


07H 


FP IP address / gateway 


MD 


MD 


Only for static IP address 


7.4.11.3.7 


08H 


FP IP address / DNS server 


MD 


MD 


Only for static IP address 


7.4.11.3.8 


09H 


FP version / Firmware version 


YES/MD 


NO 


Software version of the FP 


7.4.11.3.9 


OAH 


FP version / Eeprom version 


YES/MD 


NO 


Eeprom version of the FP 


7.4.11.3.10 


OBH 


FP version / Hardware version 


YES/MD 


NO 


Hardware version of the FP 


7.4.11.3.11 


OCH 


Emission mode 


MD 


MD 


Bitmap for activating/deactivating the 
'No Emission mode', etc. 


7.4.11.3.12 


ODH 


New PIN code 


YES/MD 


MD 


Allows modification of the PIN code 


7.4.11.3.13 



Field identifiers from OEH to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 8 IH to FFH are reserved for proprietary fields and may be freely used by implementers for coding 

of proprietary features. 

Default value: it is the value of the setting when product is manufactured: 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 

• "MD" means that a default value shall be provided by the manufacturer (could also be empty by setting the 
length to 1). 

• "YES/MD" means that a default value shall be provided by the manufacturer, which shall not be empty. 
"Base reset" impacted: describes the impact of the "Base reset" setting on this particular setting: 

• "YES" means setting is reset to default value when "Base reset" setting is activated. 

• "NO" means setting is not impacted by "Base reset" setting. 

• "MD" means manufacturer defines if the setting is impacted or not by the "Base reset" setting. 

7.4.1 1 .3.1 Field 'Current PIN code' 

The 'PIN code' field shall be coded as follows. 
Bits 



8 



Field identifier = Current PIN code 



0/1 



0/1 



Editable 



Length (L) 



l^byte 



2^byte 



3^byte 



4^byte 



Octet 
1 
2 
3 
4 
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The 'Current PEST code' field shall respect the following rules: 

• the PIN shall always have a length of 32 bits; 

• each decimal digit entered by the user, is translated into one nibble (4 bits, BCD coded). The PT shall be 
capable to accept any PIN between and 8 decimal digits (Umits included); 

• the resulting string of nibbles is padded with as many leading 'F'H nibbles as necessary to achieve a total of 
8 nibbles; 

• the result is a bitstring of 32 bits; 

• on "Read Entry"or "Edit Entry" commands from the PP the FP shall always answer with the value 'FF'H 'FF'H 
'FF'H 'FF'H in order not to disclose the actual value of this field; 

• on a "Save Entry" command from the PP, the FP shall not overwrite the stored value of the 'Current PIN code' 
field. This field is only used in order to compare the value submitted by the user with the stored value. As 
described in clause 7.4. 11.1 ('PIN code' subsection), the field value shall be changed by the FP when the field 
'New PIN code' field is successfully saved. 

EXAMPLE: A value of " 1 09 1 " (4 decimal digits entered via keypad) is translated into a bitstring pin code of 

the following value: 

"1111 nil nil nil oooi oooo looi oooi", 

MSB: PIN[31] LSB: PIN[0] 

and coded as shown in figure 60: 

|FFH|FFH|10H|91H| 
Figure 60: Example of PIN code coding 

7.4.1 1 .3.2 Field 'Clock master' 

The 'Clock master' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 






Field identifier 


= clock master 






0/1 


Length (L 


) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 
















protected 


Value 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Clock master' 
field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 3 IH. 30H stands for FP, 3 IH stands for PP. 

The behaviour of the PP and FP according to 'Clock master' field setting shall be consistent with the "Date and Time 
synchronization" feature described in clause 7.4.2. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.11.3.3 Field 'Base reset' 

The 'Base reset' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = base reset 


1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 
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'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Base reset' field 

against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30Hor 31H. 30H stands for 'No', 31H stands for 'Yes'. 
The 'Base reset' field shall respect the following rules: 

• If at least one DECT system setting, or line setting, has been set to a non default value, the 'Base reset' field 
shall be equal to 'No' when a PP performs a read command. 

• If a registered PP sets the value to 'Yes', after the save confirm command: 

AH DECT system and line settings shall be reset to their default value in the FP. 

When the base reset is complete, the FP shall carry out the 'base reset' related requirements of clauses 
7.4.1.3 ('Missed call notification') and 7.4.10.2 ('List change notification'). 

The setting shall remain set to 'Yes' until any DECT system or line setting is changed in the FP. 

Additionnally, if the FP performs a software reboot: 

■ FP may send an 'end session' command on each LiA opened session; 

■ FP shall release all exisiting LiA calls in the system by sending a {CC-RELEASE} to the 
concerned PPs. 

PP shall support the possible reception of {CC-RELEASE} (for example linked to the reboot of the FP); 

If the FP does not perform a software reboot, aU LiA sessions may remain opened until terminated by the 
PP. 

• Any attempt from a PP to set this parameter to 'No' shall result in a negative acknowledgement, with reject 
reason "procedure not allowed" from the FP (see clause 7.4.10.4.9). 

Default value: 31H ( Yes ). 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 



7.4.1 1 .3.4 Field 'FP IP address / type' 

The 'IP address type' field shall be coded as follows. 
Bits 



8 


7 


6 


5 


4 


3 


2 


1 






Field identifier = 


IP address type 






0/1 


Length (L 


) 


0/1 


Editable 


DHCP 


Static 


X 


X 


X 


PIN 
protEcted 



Octet 
1 
2 
3 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
type' field against unauthorised modification, depending on its security policy. 

'DHCP' and 'Static' properties (bit 5 and 6 of octet 3). The IP address of the FP may be assigned dynamically using 
DHCP or manually using a static address entered by the user. The two property bits are exclusive (only one bit must be 
set at a time). 

If the 'FP IP address / type' field is implemented in the FP, either 'DHCP' or 'Static' property shall be set to T (The PP 
can not set both properties to '0'). 



Bits 2 to 4 of octet 3 are reserved for further standardization and shall be set to "0". 



ETSI 



194 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



7.4.1 1 .3.5 Field 'FP IP address / value' 

The 'IP address value' field shall be coded as follows. 
Bits 



8 



6 



Field identifier = FP IP address / value 



0/1 



0/1 



Editable 



IPv4/6 



Length (L) 



l^byte 



2^byte 



3^byte 



PIN 

protected 



Octet 
1 
2 
3 



Length octet (octet 2). The length of the field shall be set to '1' when the value of the field is not defined by the user. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
type' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long); if set to 1, the format is IPv6 (16 bytes 
long). 

Address value (from octet 4): 

An IPv4 address shall always have a length of 4 bytes. 

EXAMPLE 1: A value of 192.168.213.1 is translated into an 'IP address / value' field with the following bytes: 
'C0A8D501'H. 

An IPv6 address shall always have a length of 16 bytes. 

EXAMPLE 2: A value of fdl 1:2233:4455: l:a:b:c:d is translated into an 'IP address / value' field with the 
following bytes: 'FD11223344550001000A000B000C000D'H. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 



7.4.1 1 .3.6 Field 'FP IP address / subnet mask' 

The 'IP address value' field shall be coded as follows. 
Bits 



8 


7 


6 


5 


4 


3 


2 


1 




Field identifier 


= FP IP address / subnet mask 




0/1 


Length (L 


) 


0/1 


Editable 


IPv4/6 


X 


X 


X 


X 


PIN 

protected 


l^'byte 








2"" 


Dyte 








3'" byte 





Octet 
1 
2 
3 



Length octet (octet 2). The length of the field shall be set to T when the value of the field is not specified by the user. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 

subnet mask' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes 
long). 

Subnet mask value (from octet 4): 

A subnet mask for IPv4 shall always have a length of 4 bytes. 

EXAMPLE 1: A value of 255.255.255.0 is translated into an 'IP address / subnet mask' field with the following 
bytes: 'FFFFFFOO'H. 
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A subnet mask for IPv6 shall always have a length of 16 bytes. 

EXAMPLE 2: A subnet mask corresponding to a 59-bit prefix is translated into an 'IP address / subnet mask' field 
with the following bytes: 'FFFF FFFF FFFF FFEO 0000 0000 0000 OOOO'H. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 



7.4.1 1 .3.7 Field 'FP IP address / gateway' 

The 'FP IP address / gateway' field shall be coded as follows. 
Bits 



8 



0/1 



0/1 



Field identifier = FP IP address / gateway' 



Editable 



IPv4/6 



Length (L) 



l^byte 



2^byte 



3^byte 



PIN 

protected 



Octet 
1 
2 
3 



Length octet (octet 2). The length of the field shall be set to T when the value of the field is not specified by the user. 

'PEV protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
gateway' field against unauthorised modification, depending on its security pohcy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes 
long). 

'FP IP address / gateway' value (from octet 4): The 'FP IP address / gateway' value shall always have a length of 4 

bytes (IPv4) or 16 bytes (IPv6). See the 'IP address / value' field for more information. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 



7.4.1 1 .3.8 Field 'FP IP address / DNS server' 

The 'FP IP address / DNS server' field may be included several times in the entry: main server and alternate server(s). 
The 'DNS server' field shall be coded as follows. 



Bits 



8 


7 


6 




5 


4 


3 


2 


1 


Octet 




Field identifier = 


FP IP address/ DNS server 




1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


IPv4/6 




X 


X 


X 


X 


PIN 

protected 


3 


l"byte 


4 


2™ byte 




3'° byte 









Length octet (octet 2). The length of the field shall be set to '1' when the value of the field is not specified by the user. 

'PEV protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
DNS server' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes 
long). 

'FP IP address / DNS server' value (from octet 4). The 'FP IP address / DNS server' value shall always have a length 

of 4 bytes (IPv4) or 16 bytes (IPv6). See the 'IP address / value' field for more information. 



Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 
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7.4.1 1 .3.9 Field 'FP version / Firmware version' 

The 'firmware version' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 




Field identifier 


= FP version / Firmware version 




1 


0/1 


Length (L 


) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 ^' character byte 


4 


2™ character byte 


5 







'PEV protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP version / 
Firmware version' field against unauthorised modification, depending on its security pohcy. 

Characters shall be coded as defined for UTF-8 but restricted to the 1A5 subset of characters (code point below or equal 
to 127). The length of this parameter (from octet 4) shall be of 20 octets maximum. 

Bits 2 to 7 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.1 Field 'FP version / Eeprom version' 

The 'Eeprom version' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = FP version / Eeprom version 


1 


0/1 


Length (L 


) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 ^' character byte 


4 


2™ character byte 


5 







'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP version / 
Eeprom version' field against unauthorised modification, depending on its security pohcy. 

Characters shall be coded as defined for UTF-8 but restricted to the IA5 subset of characters (code point below or equal 
to 127). The length of this parameter (from octet 4) shall be of 20 octets maximum. 

Bits 2 to 7 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.1 1 Field 'FP version / Hardware version' field 

The 'Hardware version' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 




Field identifier 


= FP version / Hardware version 




1 


0/1 


Length (L 


) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 ^' character byte 


4 


2"° character byte 


5 







'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP version / 

Hardware version' field against unauthorised modification, depending on its security policy. 

Characters shall be coded as defined for UTF-8 but restricted to the IA5 subset of characters (code point below or equal 
to 127). The length of this parameter (from octet 4) shall be of 20 octets maximum. 

Bits 2 to 7 of octet 3 are reserved for further standardization and shall be set to "0". 
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7.4.1 1 .3.1 2 Field 'Emission mode' 

The 'Emission mode' field allows to activate or deactivate the 'No emission mode' feature on the FP from on of the PPs. 
It shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 





Field identifier = Emission mode 


1 


0/1 


Length (L 




2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


0/1 


reserved 


NEM 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Emission mode' 
field against imauthorised modification, depending on its security policy. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 

Emission mode bitmap (octet 4): 

This field is a bitmap octet group. 

Bits 7 6 5 4 3 21 Meaning 

X X X X X X 'No emission mode' deactivated 

X X X X X X 1 'No emission mode' activated 

Bit 1: 'No emission' mode (NEM). If bit 1 is set, the FP shall activate the 'No emission mode' MAC service 
[NG1.M.5]. Otherwise the FP shall deactivate it. 

Bits 2 to 7 of octet 4 are reserved for further standardization and shall be set to "0". 
7.4.11.3.13 Field 'New PIN code' 

The 'New PIN code' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 






Field identifier = 


= New PIN code 






0/1 


Length (L) 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 
= 1 


l^'byte 








2™ 


Dyte 








3''' byte 


4" byte 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'New PIN code' 
field (hence the PIN) against unauthorised modification. For the field 'New PIN code', this property shall always be set 
to '1'. 

The 'New PIN code' field shall respect the following rules: 

• the PIN shall always have a length of 32 bits; 

• each decimal digit entered by the user, is translated into one nibble (4 bits, BCD coded). The PT shall be 
capable to accept any PIN between and 8 decimal digits (limits included); 

• the resulting string of nibbles is padded with as many leading 'F'H nibbles as necessary to achieve a total of 
8 nibbles; 

• the result is a bitstring of 32 bits; 

• on "Read Entry"or "Edit Entry" commands from the PP the FP shall always answer with the value FFH FFH 
FFH FFH in order not to disclose the actual value of this field; 
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• the 'New PIN code' field shall only be modified via the "Save Entry" command if a successful "Save Entry" of 
the 'Current PIN code' field (see clause 7.4.1 1.3.1) has been executed before during the current call. See also 
clause 7.4.11.1 for more information. After a successful save of the 'New PIN code' field, the value of the 
'Current PIN code' field shall also be changed to the same value. 

EXAMPLE: See example at clause 7.4.11.3.1 and figure 60. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to '0'. 

7.4.1 1 .4 Line settings list 

The following 'entry field identifier' for Une settings list are defined. 



Table 72: Entry fields for a line settings list entry 



Field 
identifier 


Field 


Defauit 
vaiue 


Base 
reset 
impacted 


Normative action/comment 


List change 
notification 
rP status 


Ciause 


01H 


Line name 


MD 


MD 


Name of the line 


M 


7.4.11.4.1 


02H 


Line id 


MD 


NO 


Line identifier 


M 


7.4.11.4.2 


03H 


Attached handsets 


MD 


MD 


List of registered handsets which are 
attached to the line 


M 


7.4.11.4.3 


04H 


Dialling prefix 


MD 


MD 


If defined, adds a prefix to called party 
numbers for calls placed on the line 





7.4.11.4.4 


05H 


FP melody 


YES/MD 


MD 


Melody of the FP linked to this line 


1 


7.4.11.4.5 


06H 


FP volume 


YES/MD 


MD 


Melody volume of the FP linked to this line. 


1 


7.4.11.4.6 


07H 


Blocked telephone 
number 


MD 


MD 


Forbidden called party numbers on the line 





7.4.11.4.7 


08H 


Multiple calls mode 
(single/multiple) 


MD 


MD 


Current mode of the line: single call or 
multiple call 


M 


7.4.11.4.8 


09H 


Intrusion call 


MD 


MD 


Intrusion call allowed (YES / NO) 


C7201 


7.4.11.4.9 


OAH 


Permanent CLIR 


YES 


MD 


Restrict number for all outgoing calls on this 
line 


M 


7.4.11.4.10 


OBH 


Call forwarding 
unconditional 


YES 


MD 


Stores the activation/deactivation codes and 
forwarding to number of the call forwading 


M 


7.4.11.4.11 


OCH 


Call forwarding on 
No answer 


YES 


MD 


Stores the activation/deactivation codes, 
forwarding to number and number of 
seconds of the call fonwarding 


M 


7.4.11.4.12 


ODH 


Call forwarding on 
Busy subscriber 


YES 


MD 


Stores the activation/deactivation codes and 
forwarding to number of the call forwading 


M 


7.4.11.4.13 


C7201 : IF intrusion call feature NG1.N.10 is implemented on FP side THEN 1^ ELSE 1. 



Field identifiers from OEH to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 8 IH to FFH are reserved for proprietary fields and may be freely used by implementers for coding 

of proprietary features. 

Default value: it is the value of the setting when product is manufactured: 

• "MD" means that a default value, if any, shall be provided by the manufacturer (could also be empty by setting 

the legth to 1). 

• "YES/MD" means that a default value shall be provided by the manufacturer (shall not be empty). 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 
Base reset impacted: describes the impact of the "Base reset" setting on the given setting: 

• "YES" means that the setting is reset to default value when "Base reset" setting is activated. 

• "NO" means that thesetting is not impacted by "Base reset" setting. 

• "MD" means "manufacturer defined", whether or not the setting is impacted by the "Base reset" setting. 
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List change notification status: 

Sending a list change notification for line setting is mandatory when a setting is modified. However, for some fields that 
do not require the display of the PP to be aware, the notification is optional or irrelevant. See also clause 7.4.10.2.2. 

The Ust shall be sorted by ascending numerical order of the 'Line id' field values. 

Only one entry per line identifier shall exist in the line settings list. In other words, two distinct entries shall never have 
the same Une id. If a PP attempts to add or modify an entry with an already existing line id in one entry of the list, the 
FP shall reject it with negative acknowledgement (see clause 7.4.10.4.9) / reject reason = 'content not accepted'. 

When the line name of a specific line is modified, the FP should automatically update the other lists where line name is 
stored (especially call lists). 

7.4.11.4.1 Field 'Line name' 

See 'Line name' field in "List access service" feature, clause 7.4.10.5.1.6. This field of the 'Line settings' list may be 
protected against unauthorised modification by the FP by use of the 'PIN protected' property (see 7.4.10.5.1.6). 

7.4.11.4.2 Field 'Line id' 

See 'Line id' field in "List access service" feature, clause 7.4. 10.5. L7. This field of the 'Line settings' list may be 
protected against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.7). 

7.4.1 1 .4.3 Field 'Attached handsets' 

The 'Attached handsets' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 





Field identifier = Attactied handsets 


1 


0/1 


Lengtii (L 




2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




0/1 


Number of registered 


handsets attached to the line 


4 


0/1 


Handset bitmap 


5 


0/1 






0/1 


Handset bitmap (continued) 


5n 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Attached 
handsets' field against unauthorised modification, depending on its security policy. 

Number of registered handsets attached to the line (octet 4): 

The number of handsets relates to the number of handsets attached to the line. The value shall be coded with the natural 
binary value, with the least significant bit in bit position "1". Allowable values are "1" to "127". 

Handset bitmap (octet group 5): 

This is a bitmap octet group, with the handset number 1 in bit position "1". A "1" indicates handset is attached to the 
line, and a "0" indicates it is not. 

Handset bitmap (octet 5n): 

Bits 7 6 5 4 3 21 Meaning 

X X X X X X 1 Handset number 1 is attached 

X X X X X 1 X Handset number 2 is attached 

X X X X 1 X X Handset number 3 is attached 

X X X 1 X X X Handset number 4 is attached 

X X 1 X X X X Handset number 5 is attached 

X 1 X X X X X Handset number 6 is attached 

1 X X X X X X Handset number 7 is attached 
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NOTE 1 : If the extension bit is "0" in the first octet (indicating presence of an additional octet), the least significant 

bit of second octet stands for handset number 8. 

NOTE 2: The format of the current field is a bit mask, it is different from the format of the number field of the 
internal names Ust (terminal id number) but represents the same handset numbers. 

7.4.11.4.4 Field 'Dialling Prefix' 

See'Number' field in "List access service" feature, clause 7.4.10.5.1.2. The field 'Dialling Prefix' maybe protected 
against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.2). 

The prefix shall be added by the FP to the called party number to any external outgoing call placed on the Une. 

The length of the field shall be set to one when the value of the field is not defined. 

7.4.11.4.5 Field 'FP melody' 

See 'Associated melody' field in "List access service" feature, clause 7.4.10.5.1.12. The field 'FP melody' may be 
protected against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.12). 

This field defines the melody to be used to ring in the FP on an incoming call on a dedicated line. 

7.4.11.4.6 Field 'FP volume' 

The 'FP volume' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = volume 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP volume' field 

against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall bein the interval '30'H..'39'H. The '30'H value stands for the minimum 
adjustement of the volume level when the FP rings, and the '39'H value is the maximum adjustment. 

7.4.1 1 .4.7 Field 'Blocked number' 

See 'Number' field in "List access service" feature, clause 7.4.10.5.1.2, except that the possible value shall be in the 
interval '30'H..'39'H, plus the '2A'H value. The field 'Blocked number' may be protected against unauthorised 
modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.2). 

The 'blocked number' field may be composed of: 

• either a single phone number value, or 

• a range of phone number values. In this case, the 'Number' field shall be equal to a sequence of one or more 
digit(s) followed by '*'. For example: "02*" represents all numbers starting with "02" digit sequence. 

When a PP attached to the line tries to place an external outgoing call on a number which is blocked, this call shall not 
be established by the FP. The FP shall release the call. 

This field may be contained several times in line settings entry. This allows to block several numbers or ranges of 
numbers. The number of times the field is included shall be defined at line setting entry creation. See clause 7.4.10.4.5 
list access 'Save entry' command procedure for details how to handle several fields of the same type in the same entry. 

The length of the field shall be set to one when the value of the field is not defined. 



ETSI 



201 



ETSI TS 102 527-3 VI .2.1 (2010-04) 



7.4.1 1 .4.8 Field 'Multiple calls mode' 

The 'Multiple calls mode' field shall be coded as follows. 
Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Multiple calls mode 


1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Multiple calls 
mode' field against unauthorised modification, depending on its security policy. 

•Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for "Single call mode", 31H for "Multiple call 
mode". 

This field is related to the "Multiple calls" feature (see clause 7.4.8) and allows to configure a multiple call line in single 
call mode. For non-multiple call lines, the value "Single call mode" shall always be used. 



7.4.1 1 .4.9 Field 'Intrusion call' 

This field is related to the "intrusion call" feature (see clause 7.4.3.8). The 'intrusion call' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier 


= Intrusion call 






1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Intrusion 
call' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for intrusion call (implicit or explicit) not 
allowed, 31H for intrusion call (impUcit or explicit) allowed. 

For "Implicit call intrusion" (see clause 7.4.3.8.1), the value also indicates the behavior of the system when a call setup 
is attempted on the hne (real call setup, vs call intrusion if the triggering conditions described in clause 7.4.3.8.1 are 
met). 



7.4.1 1 .4.1 Field 'Permanent CLIR' 

The 'Permanent CLIR' field shall be coded as follows. 
Bits 



8 



Field identifier =Permanent CLIR 



0/1 



0/1 



Editable 



Length (L) 



Value 



CLIR activation code length 



CLIR activation code 1 digit 



CLIR activation code 2"° digit 



CLIR deactivation code length 



CLIR deactivation code 1 digit 



CLIR deactivation code 2™ digit 



PIN 
protected 



Octet 
1 
2 
3 

4 

5 

5a 



6 

6a 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 
'Permanent CLIR' field against unauthorised modification, depending on its security pohcy. 
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'Value' octet (octet 4). The 'Value' octet shall be BOH or 31H. 30H stands for CLIR de-activated for all calls, 31H for 
CLIR activated for all calls. 

Each digit shall be in the interval 30H..39H, and values 23H, 2AH, 05H and 15H. 

If a PP sets or resets the value, the FP shall activate or deactivate the CLIR service in the network using the CLIR 
activation or deactivation code for all outgoing calls placed on the specified Une. This setting shall be consistent with 
the CLIR feature [NG1.N.17]. 

If the PP supports the field (according to table 9, feature [NG1.N.16], supported line settings), the PP shall make at least 

the 'Value' accessible to the user. CLIR activation and deactivation codes may not be accessible to the user on the PP 
side. However the PP shall handle correclty those codes in the edit and save commands. (PP shall perform the save 
command with the same codes received in edit confirm). 

NOTE : This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. When neither activation nor deactivation codes are necessary, the FP shall set the length of 
the field so that the field only includes the value octet. 

Default value: 30H: 'de-activated'. Default CLIR codes are "manufacturer defined". 



7.4.1 1 .4.1 1 Field 'Call forwarding unconditional' 

The 'Call forwarding' unconditional field shall be coded as follows. 
Bits 



8 



0/1 



0/1 



Field identifier =Call forwarding unconditional 



Editable 



Length (L) 



Value 



CPU activation code length 



CPU activation code 1 digit 



CPU activation code 2"° digit 



CPU deactivation code length 



CPU deactivation code 1 digit 



CPU deactivation code 2"° digit 



Call forwarding number length 



l^digit 



2^digit 



PIN 

protected 



Octet 
1 
2 
3 

4 

5 

5a 



6 

6a 



7 

7a 



Length octet (octet 2). the length of the field shall be set to T (default value) when the value of the field is not 
specified by the user (no 'Call forwarding unconditional' defined). 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Call 
forwarding unconditional' field against unauthorised modification, depending on its security pohcy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for CFU de-activated for all calls, 31H for 
CFU activated for all calls. 

The digits represent the activation/deactivation codes and the call forwarding target number. Each digit shall be in the 
interval 30H..39H, and values 23H, 2AH, 05H and 15H. 

If a PP sets or resets the field, the FP shall activate or deactivate the corresponding Call forwarding in the network for 
specified type of calls received and on the specified line using the CFU activation code or CFU deactivation code. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 
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The PP shall make at least the 'Value' and the 'Call forwarding number' configurable by the user. CFU activation and 
deactivation codes may not be accessible to the user on the PP side. However the PP shall handle correclty those codes 
in the edit and save commands. (PP shall perform the save command with the same codes received in edit confirm). 

NOTE : This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 



7.4.1 1 .4.1 2 Field 'Call forwarding on No Answer' 

The 'Call forwarding on No Answer' field shall be coded as follows. 



Bit: 



8 



4 



Octet: 



0/1 



0/1 



Field identifier =Call forwarding on No Answer 



Editable 



Length (L) 



Value 



Nb of seconds before call is fonwarded 



CFNA activation code length 



CFNA activation code 1 'digit 



CFNA activation code 2"° digit 



CFNA deactivation code length 



CFNA deactivation code 1°' digF 



CFNA deactivation code 2^digit 



Call fon/varding number length 



l^digit 



2^digit 



PIN 
protected 



1 
2 
3 

4 

5 

6 

6a 



7 

7a 



8 
Ba 



Length octet (octet 2). The length of the field shall be set to '1' (default value) when the value of the field is not 
specified by the user (no 'Call forwarding on No answer' defined). 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Call 
forwarding on No Answer' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for CFNA de-activated for all calls, 31H for 

CFNA activated for all calls. 

The digits represent the activation/deactivation codes and the call forwarding target number. Each digit shall be in the 
interval 30H..39H, and values 23H, 2AH, 05H and 15H. 

The number of seconds before triggering the forwarding shall be coded with the natural binary value, with the least 
significant bit in bit position "1". Allowable values are "0" to "64". A value of zero indicates that the choice of the 
number of seconds is left to the FP (use of a default or preferred value configured in the FP). 

If a PP sets or resets the field, the FP shall activate or deactivate the Call forwarding on No Answer' in the network for 
specified type of calls received and on the specified line using the CFNA activation code or CFNA deactivation code. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 

The PP shall make at least the 'Value' and the 'Call forwarding number' configurable by the user. Nb of seconds, CFNA 
activation and deactivation codes may not be accessible to the user on the PP side. However the PP shall handle 
correclty those codes in the edit and save commands. (PP shall perform the save command with the same codes 
received in edit confirm). 

NOTE : This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 
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7.4.1 1 .4.1 3 Field 'Call forwarding on Busy subscriber' 

The 'Call forwarding on Busy subscriber' field shall be coded as follows: 

Bit: |8|7|6|5|4|3|2 



0/1 



0/1 



Field identifier =Call forwarding on Busy subscriber 



Editable 



Length (L) 



Value 



CFB activation code length 



CFB activation code 1 digit 



CFB activation code 2™ digit 



CFB deactivation code length 



CFB deactivation code 1 digit 



CFB deactivation code 2 ° digit 



Call fonwarding number length 



l^digit 



2"° digit 



PIN 

protected 



Octet: 

1 

2 
3 

4 
5 
5a 



6 

6a 



7 

7a 



Length octet (octet 2). The length of the field shall be set to '1' (default value) when the value of the field is not 
specified by the user (no 'Call forwarding on Busy suscriber' defined). 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Call 
forwarding on Busy subscriber' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be BOH or 31H. BOH stands for CFB de-activated for all calls, 31H for 
CFB activated for all calls.7 

The digits represent the activation/deactivation codes and the call forwarding target number. Each digit shall be in the 
interval 30H..39H, and values 23H, 2AH, 05H and 15H. 

If a PP sets or resets the field, the FP shall activate or deactivate the Call forwarding on Busy subscriber' in the network 
for specified type of calls received and on the specified line using the CFB activation code or CFB deactivation code. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 

The PP shall make at least the 'Value' and the 'Call forwarding number' configurable by the user. CFB activation and 
deactivation codes may not be accessible to the user on the PP side. However the PP shall handle correclty those codes 
in the edit and save commands. (PP shall perform the save command with the same codes received in edit confirm). 

NOTE : This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 



7.4.1 1 .5 Virtual contact list and call list per line 

The default behaviour of the "List access service" feature is to share all lists between all registered PPs, independently 
of the line attachments of the PPs. 

The current procedure allows to share virtually contact or call lists (missed calls, outgoing calls, incoming accepted 
calls, all incoming calls, all calls lists) only between handsets attached to the same line. For a system implementing this 
procedure, it shall be possible to switch back dynamically to the default behavior. 

After reading or searching entries, the PP shall filter the entries that are related to a given line thanks to the Une 
identifier field. This way, the PP has a possibihty to show to the user only the calls and contacts that are related to one 
line (including the contacts that are attached to all hnes). 
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7.4.12 Calling line identity restriction (CLIR) 

7.4.12.1 Considerations 

The "Calling line identity restriction" feature defines procedures for CLIR as defined by 3GPP Technical specifications 
for Line identification supplementary services (see TS 122 081 [23]). 

This procedure allows a user to enable or to disable the presentation of its calling line identification when originating a 
call. When it is enabled, the originating network notifies the destination network that the calling party number is not 
allowed to be presented to the called party. If the called party subscribes to calling identification and the calling party 
has calling line identification restriction enabled, the called party shall receive the presentation indicator set to 
"presentation restricted" in the «CALLING-PARTY-NUMBER» IE of the {CC-SETUP}. In this case, the calling 
party's number will not be presented to the called party. 

The CLIR service may be provisioned in a permanent (for aU outgoing calls) or a temporary mode (call by call basis). 

NOTE : It should be noted that this procedure allows to configure the network activation and deactivation codes 
ftom the PP. Nevertheless, these codes may be considered not being common end-user configurable but 
reserved for a well-informed user (and modified less often). For example call forwarding codes might be 
available through an advanced menu on PP side. Call forwarding activation may be available through 
other menus. 

7.4.12.2 Permanent CLIR mode (all calls) 

This procedure allows a user to enable or to disable the presentation of its calling line identification for all following 
outgoing calls for a specified line. 

When implementing the feature, the FP shall set bit a3o of the "Extended higher layer capabiUties (part 2)" 
(see EN 300 175-5 [5], clause F.3). 

To enable (respectively disable) the permanent CLIR mode, the user shall set (respectively reset) the 'Permanent CLIR' 
field of the specified line in the "Line settings" list (see the "List access service" feature [NG1.N.16]). When this mode 
is enabled (respectively disabled), the FP shall invoke the permanent mode by sending the permanent CLIR activation 
(respectively deactivation) request to the network for the specified line. 

NOTE 1: The current procedure does not state anything about the availability or not of the service on Network side. 
PP1 

Permanent CLIR FP Network 

invocation on line u I 



line settings start session 



line u settings: 'Permanent CLIR' field set to '31 H' 



line settings end session 



Use of line u for sending 
a 'Permanent CLIR 
invocation' / 



Figure 61 : Permanent CLIR mode invocation 

When the permanent mode is deactivated, it shall be always possible to use the temporary mode. 

NOTE 2: It should be noted that the permanent mode can also be provisioned by using the temporary mode for each 
call. 
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7.4.12.3 Temporary CLIR mode (call by call) 

This procedure allows a user to disable the presentation of its calling line identification at the time of the call request. 

If the user requests a temporary CLIR mode when originating a call, the PP shall insert before the telephone number in 
the «MULTI-KEYPAD» IE the CLIR invocation temporary digits sequence. 



PP1 

Temporary CLIR 
invocation on line u 
-I- 



FP 



if CO-SETUP is used: 



GC-SETUP 



« MULTI-KEYPAD, < Keypad info = 'CLIR invocation' > 



if CC-INFO is used: 



« MULTI-KEYPAD, < Keypad info = 'CLIR invocation' > 



CC-SETUP 



CC-INFO 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > >: 



Networl< 



Use of line u for calling 
'CLIR invocation + 
called number' 




Figure 62: Temporary CLIR mode invocation 

A temporary CLIR request shall override a permanent deactivated CLIR mode. 

NOTE 1: It should be noted that the temporary mode can also be provisioned directly by the user by dialling the 
CLIR temporary digits sequence. 

NOTE 2: As the network temporary CLIR invocation digits sequence is network dependent, the sequence should be 
configurable on PP side. 

7.4.13 Call forwarding (external calls) 
7.4.13.1 Call forwarding common requirements 

The "Call Forwarding" feature defines procedures for Call Forwarding Unconditional (CFU), Calls Forwarding on No 
Answer (CFNA), and Calls Forwarding on Busy subscriber (CFB) as defined by 3GPP Technical specifications for Call 
Forwarding supplementary service Stage 1, 2 and 3 (see [24J, [25] and [26]). 

The call forwarding service enables the user to request to forward aU incoming external calls to another external number 
when some conditions are met. The FP shall relay the procedure activation and deactivation to the network. 

NOTE 1: Depending on these conditions, the call may or may not be presented to the user before the forwarding 
occurs. 

NOTE 2: If the call is presented and the user picks up the presented call, forwarding of the call does not take place. 

The "Call forwarding (external calls)" procedure uses the Call forwarding field of Line settings (see [NG1.N.16] List 
access service), i.e. the forwarding of calls applies to incoming calls on a specified line. When list change notification is 
supported by the FP, a notification shall be sent (see clause 7.4.10.2 List change notification) when 'Call forwarding' 
field is modified. 



NOTE 3: This may allow for example to display on handsets that calls are forwarded. 
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NOTE 4: It should be noted that this procedure allows configuring the network activation and deactivation codes 
from the PP. Nevertheless, these codes may be considered not being common end-user configurable but 
reserved for a well-informed user. As a consequence, it is recommended not to edit them systematically 
on the PP side. For example these codes could be available in more "advanced" setting menu. 

The current procedure does not state anything about the availability nor the implementation of the service on Network 
side. It is considered by default that the operation is successful on Network side. 

Nevertheless, in case a network negative confirmation is received following the call forwarding service request, the FP 
shall notify the PP that the service cannot be provided using a negative acknowledgement tone (see "tones provision" 
feature in clause 7.4.15). 

Call forwarding shall always be invoked for a specific line, not for all lines at the same time. Notifications shall also 
apply to the specified Une (Value "AH lines" for line identifier shaU not be used in CALL INFORMATION IE). 

NOTE 5: Possible implementations on Network side is not part of the current specification, please find some 
examples bellow just for information: 

EXAMPLE 1: Call forwarding invocation may be done by performing a speech call to a call forwarding platform 
with sending of the code at call setup. 

EXAMPLE 2: Negative confirmation, in case of wrong code, may be done by a call rejection from network side. 

EXAMPLE 3: Result of the operation may be sent via audio inband information, in such a case, the list access 
session may end up in a speech session so that the user may hear the result of its call forwarding 
operation. 

7.4.13.2 External Call Forwarding Unconditional (CFU) to external number 

This procedure allows the user to forward all external incoming calls on a specified line to a given extemal number, 
without any triggering condition. 

To activate (respectively deactivate) the Call Forwarding Unconditional (CFU) mode, the user shall set (respectively 
reset) the 'Call forwarding unconditional' field of the specified line in the "Line settings" list (see the "List access 
service" feature [NG1.N.16]) with the IA5 coded digits of the forwarded-to telephone number. Network activation and 
deactivation codes are also saved as part of the field (although they might not be modified on PP side very often nor in 
the same menu). 

When this mode is activated (respectively deactivated), the FP shall invoke the call forwarding mode by sending the 
CFU activation (respectively deactivation) request to the network for the specified line. 
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PP1 

_l_ 



FP 



Network 



Line settings start session 



Edit and save Line u settings: 'Call fonward unconditional' 
field set to '31 'H + fonwarded-to number (+network codes) 



Line settings end session 



If request accepted 



Activate CPU for 
line u 




FP notifies all PPs 
attached to this 



FACILITY 



«EVENTS NOTIFICATIONS, 
<List change indication, Line settings, N> > 
« CALL-INFORMATION, Lineld » 



If request reiected 
4 



CC-INFO 



<< SIGNAL, '09'H » 




If required by the tone 
provision feature 

I 



Figure 63: CFU mode invocation 



7.4.13.3 External Call Forwarding on No Answer (CFNA) to external number 

This procedure allows the user to forward all external incoming calls on a specified line to a given external number, 
when the call is presented but not answered within a specified number of seconds. 

To activate (respectively deactivate) the Call Forwarding on No Answer (CFNA) mode, the user shall set (respectively 
reset) the 'Call forwarding on No Answer' field of the specified line in the "Line settings" list (see the "List access 
service" feature [NGLN.16]) with the IA5 coded digits of the forwarded-to telephone number and the number of 
seconds. Network activation and deactivation codes are also saved as part of the iield (although they might not be 
modified on PP side very often nor in the same menu). 

The number of seconds before triggering the forwarding shall be coded in binary value. A value of zero indicates that 
the choice of the number of seconds is left to the FP (use of a default or preferred value configured in the FP). 

When this mode is activated (respectively deactivated), the FP shall invoke the call forwarding mode by sending the 
CFNA activation (respectively deactivation) request to the network for the specified hne. 
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PP1 



FP 



Network 



Line settings start session 



Line u settings: 'Call forward on No Answer' field set to 
'31 'H + nb of seconds + fonwarded-to number 
(+ network codes) 



X 



Line settings end session 



If request accepted 



Activate CFNA for 
line u 





FP notifies all PP 

attached to the line 



FACILITY 



«EVENTS NOTIFICATIONS, 
<List change indication, Line settings, N> > 
« CALL-INFORMATION, Lineld » 



If request reiected 



CC-INFO 



If required by the tone 
provision feature 



Figure 64: CFNA mode invocation 



7.4.13.4 External Call Forwarding on Busy subscriber (CFB) to external number 

This procedure allows the user to forward all external incoming calls on a specified line to a given external number, 
when the Une is busy. 

To activate (respectively deactivate) the Call Forwarding on Busy subscriber (CFB) mode, the user shall set 
(respectively reset) the 'Call forwarding on Busy subscriber' field of the specified line in the "Line settings" list (see the 
"List access service" feature [NG1.N.16]) with the IA5 coded digits of the forwarded-to telephone number. Network 
activation and deactivation codes are also saved as part of the field (although they might not be modified on PP side 
very often nor in the same menu). 

When this mode is activated (respectively deactivated), the FP shall invoke the call forwarding mode by sending the 
CFB activation (respectively deactivation) request to the network for the specified line. 
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PP1 

_l_ 



FP 



Network 



Line settings start session 



Line u settings: 'Call fonward on Busy subscriber' field set 
to '31 'H + fonwarded-to number (+ network codes) 



Line settings end session 



If request accepted 



If request 



Activate CFB for 
line u 



FP notifies all PR 
attached to the line 



FACILITY 



«EVENTS NOTIFICATIONS, 
<Llst change Indication, Line settings, N> > 
« CALL-INFORMATION, LIneld » 



ejected 



CC-INFO 



If required by the tone 
provision feature 



Figure 65: CFB mode invocation 



7.4.14 DTMF handling 

7.4.14.1 Uplink DTMF transmission 

The sending of Dual-Tone Multi-Frequencies (DTMF) to the network shall correspond to the sending of dialled digits 
on PP side at call setup or in active state (call connected). 

NOTE : For the additional support of variable length DTMF please refer to EN 300 444 (GAP) [12], clause 8.10, 
"Sending keypad information" and to clause D.2.2 of EN 300 175-5 [5]. 

7.4.1 4.1 .1 Uplink DTMF transmission at call setup when FP connected to classic switching 

network 

The system shall use DTMF mechanism at Network call setup, to transmit the called party number in a classic network 
switching circuit (use case on PSTN networks for example): 

• The PP shall send a «MULT1-KEYPAD» or «KEYPAD» information element to the FP that conveys 
dialed digits. 

• The PP shall not generate any in band audio DTMF. 

• The FP shall manage this keypad information correctly to send the DTMF to the network. The behaviour of 
the FP towards the network is described in clause D.l. 

• For PSTN calls, the FP should mute the downlink audio stream sent toward the PP (in order to avoid echo). 
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NOTE : The current procedure does not restrict the possible outgoing call methods. Using EN 300 444 [12], 

clause 8.3 "Overlap sending" procedure is one possible method among others in the present document. 

PP FP Network 



OO-ot 1 Ur 
► 


CALL SETUP 
< ► 


^ CC-SETUP-ACK 


In band generation 
or 

out of band siqnallinq 
■ ► 


«Codec List = Chosen codec» 
«Progress Indicator = Inband 
information» 

<Cr^ U-plane connected '""^^^ 
CC-INFO 


► 

«Multi-keypad = Dialled digits» 

CC-INFO 

^ 




«Multi-keypad = Dialled digits» 





Figure 66: Using overlap sending and DTIUIF to establisli a call 

7.4.14.1.2 Uplink DTMF transmission when connected 

The system shall be capable of sending DTMF to the network when call is estabUshed on network side in order to send 
some voice menu navigation commands 

Aftera {CC-CONNECT} message : 

• The PP shall send a «MULTI-KEYPAD» or «KEYPAD» information element to the FP that conveys 
dialed digits. 

• The PP shall not generate any in band audio DTMF. 

• The FP shall manage this keypad information correctly to send the DTMF to the network. The behaviour of 
the FP towards the network is described in clause D.l. 

PP FP Network 







<C!^ Call established J^Z>- 


CC-INFO 

>■ 


In band generation 
or 

out of band siqnallinq 
■ ► 


«IVIutli-l<eypad = Dialled digit» 
CC-INFO 




«Multi-keypad = Dialled digit» 





Figure 67: Sending DTIUIF when a call is established 



7.4.14.2 Downlink DTMF reception 

The system shall be capable of receiving some Dual-Tone Multi-Frequency (DTMF) from the network. These DTMF 
shall correspond to the sending of dialled digits from the remote party. 
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Upon reception of the DTMF from the network, there are two possible behaviours on FP side: 

• If DTMF are received in band from the network, the FP shall play transparently the DTMF as in band audio to 
the PP. 

• If DTMF are received out of band from the network, the FP may generate the DTMF as in-band audio in the 

active codec format. 

When connected to PSTN networks, the in-band generation method is used by the FP. 

If the FP is able to place calls on several hnes from different networks that use different DTMF methods, the FP shall 
adapt the downlink DTMF transmission on a line by line basis. 

The format of in band DTMF is given in clause D.2. 



PP 




U-plane connected 



FP 



Network 




External Call 




If DTMF received in band 




In band DTMF in active 




In band DTMF 



If DTMF received out of b; ind^ 



In band DTMF in active 



Out of band signalling 



Figure 68: Downlink DTiUlF reception possible cases 
7.4.14.3 Local DTMF feedback of dialled digits 

This procedure applies to a New Generation DECT system connected to an IP packet based network (like VoIP over the 
Internet) or connected to a PSTN network. It clarifies and simplifies the specific case where the system implements a 
local DTMF feedback in order to avoid non-interoperable or more complex implementations with echo in the FP. 

When a call is established on network side, when the user presses a digit key, it is recommended that the user gets a 
feedback to confirm that the key press was taken into account. Several implementations are allowed, this feedback may 
be: 

• a simple "bip", 

• a local DTMF generation corresponding to the dialled digit, or 

• a visual indication of the digits. 

Especially for PP without display capabilities, it is recommended to generate the corresponding local DTMF instead of 
a simple "bip" generation for ergonomic reason. If such a mechanism is implemented in the system, the DTMF shall be 
generated locally by the PP and not by the FP. It is recommended that this DTMF generation respects also the 
guidelines given in clause D.3. 

This echo of the DTMF shall remain local: 

• The recommended implementation is to mute temporarily the audio transmit path from the PP in order to avoid 
acoustic echo. 

• No additional DTMF in band sending from PP to FP shall be performed as it could interfere with 
procedure 7.4.14.1 Uplink DTMF transmission. 



The FP shall not provide this feedback even for PSTN calls. 
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NOTE: Please note that some mobile phone devices do not implement any DTMF generation (only visual 
feedback is used). 



PP 



FP 



Network 




for each digit 







<::CZ '^^l' established 


CC-INFO 


In band generation 
or 

out of band signalling 
'■ ► 


► 

«Mutli-keypad = Dialled digit» 

CC-INFO 




«Multi-keypad = Dialled digit» 





Figure 69: Local DTMF echo of dialled digits once call is established on network side 

The PP may additionally use the same mechanism in the following cases : 

1) When digit keys are pressed even if no SETUP is sent afterwards (case where you dial and then cancel the 
call). 

2) When digit keys are pressed before SETUP (pre-dialling method). 

3) When digit keys pressed after SETUP (post dialling method). See figure 66 for details. 



PP 



FP 



VoIP Network 



Hook off 




for each digit 



CC-SETUP 



CC-SETUP-ACK 



«Codec List = Chosen codec» 
«Progress Indicator = Inband 
information» 



U-plane connected 




CC-INFO 



«IVIulti-keypad = Dialled digits» 

CC-INFO 
«Multi-keypad = Dialled digits» 



CALL SETUP 



Out of band signaling 



Figure 70: Local DTMF echo of dialled digits after call setup 

For GAP PPs, the FP may optionally send an inband feedback of DTMF from FP to PP. 

7.4.15 Tones provision 

7.4.15.1 General considerations 

The "Tones provision" feature describes the respective roles of the PP and the FP for tones provision to the user during 
an ongoing call. A tone may be related to the active call or to another call. 



NOTE: The provision of "ringtones" or melodies is out of the scope of the "Tones provision" feature. 
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This feature is compatible with other features of the present document such as the "Multiple lines" [NG1.N.14] and 
"Multiple calls" [NG1.N.151 features. 

Active call progress tones. It is recommended to provide tones indications while a call is in progress since silence may 
cause a user to believe that nothing is happening. In that respect, the "Tones provision" feature is intended to indicate to 
the user that the call is progressing, so as to prevent him from terminating the call prematurely. 

Some information is also given in annex E about tones format. 

As described in the following clauses, there are 3 exclusive methods (procedures) to provide tones on the NG-DECT 

system: 

• Method 1- Tones provision by the system / IE «SIGNAL» method (NG-DECT Part 3 FP in front of 
NG-DECT Part 3 PP) as defined in clause 7.4.15.2.1. 

• Method 2- Tones provision by the system / in band method (NG-DECT Part 3 FP in front of GAP or 
NG-DECT Part 1 PP) as defined in clause 7.4.15.2.2. 

• Method 3- Transparency to tones provision by the network/PBX (in band tone generated by the network) as 
defined in clause 7.4.15.3. 

NG-DECT Part 3 PP: 

PP shall support all methods. The PP will receive an IE «SIGNAL» or an in-band tone and shall be able to 
play/generate the corresponding tone as far as required by table 73. From the PP point of view, method 2 and 3 are very 
close. 

NG-DECT Part 3 FP: 

For each tone, the FP shall use only one method toward a given PP to provide the tone. (For example dial tone and busy 
tones may be generated from the network, method 3, whereas negative acknowledgment tone is generated with 
method 1). 

Use of method 3 for a given tone depends on the network to which the FP it is connected to and does not depend on the 
PP type. 

Table 73 summarises the tones scenarios for a NG-DECT Part 3 FP. 



Table 73: Possible scenarios for a NG-DECT Part 3 FP regarding tones 



Tones 


Call type 


Towards a NG-DECT Part 3 PP 


Towards a NG-DECT Part 1 PP or 










GAP PP 






Status 


Method used 


Status 


Method used 


Ring back tone 


Internal 


M 


1 


M 


2 




External 


M 


1 or 3 


M 


2 or 3 


Busy tone 


Internal 


M 


1 


M 


2 




External 


M 


1 or 3 


M 


2 or 3 


Call Waiting 


Internal 


M 


1 

(no Tones off needed) 





2 




External 


M 


1 

(no Tones off needed) 
or 3 





2 or 3 


Intercept tone 


N/A 


M 


1 

(no Tones off needed) 





2 


Negative 

acknowledgment 

tone 


N/A 


M 


1 

(no Tones off needed) 





2 


Dial tone 


Internal 





1 





2 




External 





1 or 3 





2 or 3 


Off tiook warning 


Internal 





1 





2 


tone 


External 





1 or 3 





2 or 3 


Networl^ congestion 


External 





1 or 3 





2 or 3 


tone 
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7.4.15.2 Tones provision by tine system 

This procedure applies to internal call and to all external calls (first or parallel) when the network does not provide 
tones. As a consequence, tones shall be generated by the DECT system. 

However, in order to limit the complexity of the FP, a distinction is made between two cases: 

• NG-DECT Part 3 systems: NG-DECT Part 3 FP in front of a NG-DECT Part 3 PP. 

• Mixed systems: NG-DECT Part 3 FP in front of a GAP or NG-DECT Part 1 PP. 

7.4.1 5.2.1 Tones provision for a NG-DECT Part 3 FP in front of a NG-DECT Part 3 PP 

When an external or internal call is performed, the system shall provide the following tones to the user: 

• Ring-back tone. 

• Busy tone. 

• Call waiting tone (see clause 7.4.3.5.2). 

• Intercept tone (see clauses 7.4. 16.2 and 7.4.3.8 (from FP to PP). 

• Negative acknowledgement tone (see clause 7.4.3.4). 

In addition, the system may provide the following tones to the user: 

• Dial tone. 

• Off-hook warning tone. 

• Network congestion tone (external calls only). 

As a consequence to this, the PP shall support at least the following IE «SIGNAL» values defined in 

EN 300 175-5 [5], clause 7.6.8: Ring-back tone on. Busy tone on. Call waiting tone on. Intercept tone on. Negative 

acknowledgement tone. Tones Off. 

Additionally, it is recommended that the PP supports the following values: Dial tone on, Off-hook warning tone on. 
Network congestion tone on. This will increase the interoperabihty with a FP requesting these optional tones. 

The 'tone capability' field within the «Terniinal capability» IE shall be correctly set in accordance to 

EN 300 175-5 [5]. However, no specific value is requested by the current procedure (as relying on the NG-DECT Part 3 

capability flag of the IE «Terminal capability» from the PP is sufficient for the FP implementation). 

For each one of the implemented tones hsted above, on the basis of the signalhng received from the network, the FP 
shall send IE «SIGNAL» in the correct CC messages to the PP to request a tone generation. 

Upon reception of these «S1GNAL» lEs, the PP shall generate the corresponding tone. It shall be generated in 
consistency with the active codec of the ongoing call. For stopping the tone generation, the PP shall respect the 
following: 

• For Intercept tone, negative acknowledgement tone and call waiting tone, the PP shall stop the generation by 
itself (as they are very short tones). 

• For all other tones, the tone shall be generated by the PP until reception of another tone request (e.g. Tones off 
or other tone) in any Call control message 

AddtionnaUy, for the call waiting tone, the FP may re-send additional IE «SIGNAL» with 'call waiting tone on' value 
in order to repeat this short tone in the PP as long as the call waiting is presented by the FP to the PP. The PP shall 
generate the short call waiting tone at reception of each IE «SIGNAL». 

Figure 71 shows an example of external call where a NG PART3 PP generates tones. In this figure, the SIP protocol 
exchanges between the FP and the network shall be considered as an example and not as standardised exchanges. They 
are given here only to provide a better understanding of the tone feature. 
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NG PART3 PP FP SIP Network 



Hook off 


CC-SETUP 


INVITE (SDP:G722, ...) 
^ 


► 

GG-SETUP-ACK 
■M 


CC-INFO 


-M 

«Signal = Dial tone on» 


1 Generate dial tone ' 

1 ' 




CO- INFO 


► 

«Multi-keypacl = Dialled digits» 

CC-GALL-PROG 
■M 


100 TRYING 




183 RINGING (SDP: G722) 
■M 


«Signal = 'Tones off'» 
GG-ALERTING 




«Signal = Ring-back tone on» 


200 OK (SDP: G722) 


Generate ring-back tone 




AGK 




GG-GONNEGT 



«Codec List = G.722» 
«Signal = Tones off'» 

<^^^^^^ U-plane connected '^"^^> 

GG-INFO 


► 

BYE 


■M 


M 

«Signal = Off-hook warning tone on» 


1 Generate off-hook warning tone | 


Hook on 


GG-RELEASE 


► 

GG-RELEASE-GOM 


-M 



Figure 71 : NG PARTS PP provides tones during SIP external call 

Figure 72 shows an example of internal call where a NG PART3 PP generates tones. In this figure, the SIP protocol 
exchanges between the FP and the Network shall be considered as an example and not as standardised exchanges. They 
are given here only to provide a better understanding of the tone feature. 
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NG PARTS PP FP PP2 





CC-SETUP 






«Basic Service=98» 

«Codec List = G.722, G726» 


If PP2 is free 


CC-CALL-PROC 


LCE_REQUEST_PAGE (long) 


Hook on 


► 

CC-SETUP 
»> 


M 

«Signal = Ring-back tone on» 


«Basic Service=98» 

«Codec List=G.722, G726» 

CC-CONNECT 


1 Generate ring-back tone 






CC-CONNECT 




«Codec List = G.722» 

CC-CONNECT-ACK 




«Coclec List = G.722» 
«Signal = 'Tones off' » 

CC-INFO 


► 

CC-RELEASE 
■M 


CC-RELEASE-COM 




^^Rinnal = Off-hnnk warninn tnne niT>-> 






► 


1 Generate off-hook warning tone 1 


















If PP2 is not free 


CC-INFO 








■< 

«Signal = Busy tone on» 


Generate busy tone 










Hook on 


CC-RELEASE 






► 

CC-RELEASE-COM 
-M 





Figure 72: NG PARTS PP provides tones during Internal call 



7.4.15.2.2 Tones provision for a NG-DECT Part 3 FP in front of a GAP or NG-DECT Part 1 
PP 

The aim of this procedure is to guarantee some minimum backward inter-operabihty with legacy PPs. 
When an external or internal call is performed, the system shall provide the following tones to the user: 

• Ring-back tone. 

• Busy tone. 

In addition, the system may provide the following tones to the user: 

• Call waiting tone (see clause 7.4.3.5.2 "Call waiting indication"). 
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Intercept tone (see clause 7.4.16.2 "Headset call interception" and clause 7.4.3.8 "Call intrusion" (from FP to 
PP))- 

Negative acknowledgement tone (see clause 7.4.3.4 Sending negative acknowledgement). 
Dial tone. 



• Off-hook warning tone. 

• Network congestion tone (external calls only). 

Fore each of the implemented tone listed above, on the basis of the signalling received from the network, the FP shall 
generate the correct in-band tone toward the PP. 

NOTE: It is preferable that the in-band tone is generated by the FP in the current active codec of the 

communication. However alternative implementation is also allowed. For example, the FP may switch or 
choose narrow band codec in order to "fall back" into narrow band before generating the tone. 

For each implemented tone, the FP shall not send any «SIGNAL» IE to the PP as this could lead to double 
generation effects (on FP plus PP sides). 



7.4.15.2.2.1 Indication of availability of in-band tones 

The FP shall indicate availability of in-band tones to the PP by connecting the U-plane, either: 

• by transmitting the «PROGRESS INDICATOR» information element indicating "in-band information or 
appropriate pattern now available" in an appropriate message (e.g. {CC-SETUP-ACK}, {CC- ALERTING}, 
{CC-CALL-PROC}...); 

• by sending the {CC-CONNECT} message. 

NOTE 1 : The selected codec will be confirmed at the latest in the same message. 

NOTE 2: The FP should avoid sending the «PROGRESS INDICATOR» information element in a {CC-INFO}, 
either by opening the U-plane early in call setup stages or by using {CC-CONNECT}. In effect, the 
support of «PROGRESS INDICATOR» is not defined as mandatory for {CC-INFO} on PP side in 
EN 300 444 (GAP) {12] nor in TS 102 527-1 {21]. 

NOTE 3: The current procedure does not strictly mandate the sending of «PROGRESS INDICATOR» from FP 
as there are two methods for connecting the U plane. This is also consistent with the optional status of 
«PROGRESS INDICATOR» sending from FP in EN 300 444 (GAP) {12] and in TS 102 527-1 {21]. 

The PP shall accept these in-band tones in the active codec and therefore not replace them with locally generated tones 
(if available). 

Figure 73 shows an example where the FP indicates the availability of call progress tones to the PP using the 
«PROGRESS INDICATOR» information element. In this figure, the SIP protocol exchanges between the FP and the 
Network shall be considered as an example and not as standardised exchanges. They are given here only to provide a 
better imderstanding of the "Tones provision" feature. 
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PP 



FP 



SIP Network 



Hook off 



«Codec List = Chosen codec» 
-\< Progress lndicator= Inband information » 



Hool< on 



CC-SETUP 



CC-SETUP-ACK 




U-plane connected 




CC-INFO 



« IVIulti-l^eypad = Dialled digits» 

CC-CALL-PROC 



CC-ALERTING 




Generate ring-back tone 



CC-CONNECT 




INVITE (SDP: G722, 



100 TRYING 



183 RINGING (SDP: G722) 



200 OK (SDP: G722) 



ACK 



Call established 



^ - 1 




« ; ' ' Generate off-hook warning tone '> 

~~"^~'~*"' — ' — """" 

CC-RELEASE 
► 





CC-RELEASE-COM 


■M 




BYE 



Figure 73: FP provides tones during external call using progress indicator 

Figure 74 shows an example where the FP indicates the availability of call progress tones to the PP using the 
{CC-CONNECT} message. In this figure, the SIP protocol exchanges between the FP and the Network shall be 
considered as an example and not as standardised exchanges. They are given here only to provide a better understanding 
of the "Tones provision" feature. 
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PP 



FP 



SIP Network 



Hook off 



Hook on 



CC-SETUP 
► 


INVITE (SDP:G722, ...) 


CC-CONNECT 




«Codec List = Chosen codec» 

<C^^^^^^ U-plane connected "^^^^^^^ 
, -I 


z'J" Generate dial tone (optional) | 
CC-INFO 


► 

« Multi-keypad = Dialled digits» 


^ 

100 TRYING 



183 RINGING (SDR: G722) 




200 OK (SDP: G722) 







ACK 

► 




<^ Call established 





BYE 


. c ; ' ' Generate off-hook warning tone 





CC-RELEASE 


► 

CC-RELEASE-COM 






Figure 74: FP provides tones during external call using {CC-CONNECT} 



Figure 75 shows an internal call example where the FP indicates the availabiUty of call progress tones to the PP using 
the « PROGRESS INDICATOR» information element. In this figure, the SIP protocol exchanges between the FP 
and the Network shall be considered as an example and not as standardised exchanges. They are given here only to 
provide a better imderstanding of the "Tones provision" feature. 
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PP1 



FP 



PP2 



Hook off 



CC-SETUP 



«Basic Service=98» 

«Codec List = G.722, G726» 



If PP2 is free 



LCE_REQUEST_PAGE (long) 



CC-CALL-PROC 



«Codec List = chosen codec» 
«Progress lndicator= Inband information » 



CC-SETUP 




«Basic Service=98» 
«Godec List=G.722, .. 



Generate ring-back tone 



G726» 



CC-CONNECT 



Pick up 



CO-CONNECT 



«Oodec List = chosen codec: ■> 



CC-CONNECT-ACK 




Call established 



Generate off-hook warning tone 




CO-RELEASE 



Hook on 



00-RELEASE-OOM 



If PP2 is busy 



Hook on 



CC-SETUP-ACK 



«Codec List = chosen codeo > 
«Progress lndicator= Inband information >> 




Generate busy tone 



CO-RELEASE 



CO-RELEASE-OOM 



Figure 75: FP provides tones during Internal call using progress indicator 



Figure 76 shows an internal call example where the FP indicates the provision of call progress tones to the PP using the 
{CC-CONNECT} message. 
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PP1 



FP 



PP2 



Hook off 



CC-SETUP 



«Basic Service=98» 

«Codec List = G.722, G726» 



If PP2 is free 



LCE_REQUEST_PAGE (long) 



CC-CONNECT 



«Codec List = chosen codec» 



CC-SETUP 




«Basic Service=98» 

«GodeG List=G.722, G726» 



CC-CONNECT 



Pick up 



«Godec List = chosen codec>|> 
CG-CONNECT-ACK 




Call established 



Generate off-hook warning tone 




Hook on 



GG-RELEASE 



CC-RELEASE-GOM 




Figure 76: FP provides tones during Internal call using {CC-CONNECT} 

7.4.15.3 Transparency to tones provision by tine network or PABX 

This procedure applies to a FP when a call is placed on a network or PABX that provides in-band tones (e.g. PSTN, 
private network or PABX). 

When the FP recognizes the used network or PABX as a network providing in-band tones, the FP shall not generate 
in-band tones or request PP tone generation. 

The FP shall indicate availability of in-band tones to the PP by connecting the U-plane. Connection of U-plane 

is described in clause 7.4.15.2.2.1. 

The FP shall transparently play network or PABX originating audio in-band tones toward the PP in the U-plane. 

Figure 77 shows an example where external call is placed on a Network which provides tones. In this figure, the 
protocol exchanges between the FP and the Network shall be considered as example and not as standardised exchanges. 
They are given here only to provide a better understanding of the "Tones provision" feature. 
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PP 



FP 



Network 



Hook off 



CC-SETUP 



CALL SETUP 



If the FP uses "Progress indica 



or 



CC-SETUP-ACK 



«Codec List = Chosen Codec» 
Progress Indicator = Inband information » 



U-plane connected 




In band tones In active codec 



CC-INFO 



« Multi-keypad = Dialled digits» 

CC-CONNECT 



If the FP does not use "Prog res 



s indicator" 



CC-CONNECT 



«Codec List = Chosen Codec» 




U-plane connected 




In band tones in active codec 



CC-INFO 



« Multi-keypad = Dialled digits » 



Hook on 



CC-RELEASE 



CC-RELEASE-COM 



Figure 77: Network provides tones during PSTN external call 



7.4.16 Headset management 



7.4.16.1 



Headset considerations 



The "Headset management" feature defines a set of procedures that allow a better support of wideband headset PPs 
within an NG DECT system. This feature has been designed to guarantee a minimum of interoperability of NG DECT 
Part 3 systems with NG DECT Part 3 headsets without defining a complete new headset profile, while impacting only 
slightly the NG DECT PART3 FP implementation. 

This feature simplifies the use of headsets for customers while remaining compatible with the basic and extended 
telephony features defined in the present document (call transfer, call intrusion, parallel calls, etc.). See clause 7.4.16.8 
for compatibility details. 

When implementing the "Headset management" feature, the HPP shall set the corresponding terminal capability bit: 
"Support of the Headset management feature". 

For subscription registration, an HPP shall use the "0000" pin code value, as there is no numeric keypad on the HPP. 
The HPP should also follow as much as possible the "Registration mode automatic access" procedure (see 
clause 7.10.1.3.1), and also the "Searching mode request procedure" (see clause 7.10.1.2.3), with the restriction that no 
keypad shall be used. 

NOTE: The user may change the PIN code of his/her system at any time and from any PP. But the PE^ code will 
have to be set to default 0000 value at least temporarily for the HPP registration procedure to be 
successful. 
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For the following procedures, a headset PP may interact with any registered standard PP of the DECT system. 

7.4.1 6.2 Headset call interception 

This procedure allows to dial an outgoing call on a handset and to continue with the call on a headset. But this 
procedure also appUes when a PP is involved in a call to switch the call to the headset PP. 

7.4.16.2.1 Initiation of the call 

The outgoing call shall be initiated from any of the registered PPs using the PP keypad. The HPP shall then initiate the 
call interception procedure, as defined in clause 7.4.16.2.2. 

An HPP should always initiate outgoing calls using a 'call interception request' except in the following specific use 
cases: 

• redial of the last outgoing call (see clause 7.4.16.4); 

• redial of the last incoming call (see clause 7.4.16.5). 

7.4.16.2.2 Call interception 

This procedure mainly applies to an HPP willing to replace a PP involved in an existing ongoing call. The replaced PP 
may be attached to the same Une or not. 

NOTE 1: The "Call interception" procedure also applies in the following two cases: 

■ a standard PP tries to intercept a call of another PP; 

■ a standard PP tries to intercept a call of an HPP. 

In these cases, it is necessary to replace the term "PP" with "HPP and/or "HPP" with "PP", as appropriate 
in the following text of the clause to be appUcable. 

NOTE 2: "Call interception" is another way to carry out a call transfer in which the transfer is triggered from the 
targeted PP. 

The call interception shall be considered as successful if the following two conditions are met: 

• Condition 1: There is a single active call (on one PP) in the system (this call shall already be in call setup, call 
proceeding or connected state). 

• Condition 2: Call interception is allowed on this PP. In other words, the value of 'Call interception' parameter 
in the 'internal names' list is set to 'Allowed' value for this PP. 

When a PP is involved in a call, an HPP willing to intercept this call in order to be connected with the remote party 
instead of the PP, shall attempt to place a call with a {CC-SETUP}: 

• using the 'Normal call setup' basic service; 

• together with the "Call interception request" control code '1C50 2A'H transmitted in a «MULTI-KEYPAD» 
information element in the {CC-SETUP} message (see clause 7.4.3.2). 

Successful case: if the two conditions for successful call interception above are met, the DECT system behaviour shall 
be the following: 

• The intercepted call between the HPP and the remote party is considered as a standard internal or external call. 
The 'call identifier' assigned by the FP for this call shall be the 'call identifier' for the intercepted call. 

• As soon as the control code is received, the FP shall answer the HPP with a {CC-CALL PROC} message, 
including a «CALL E^ORMATION» IE containing: 

the call id of the intercepted call; 

the call status "CS call proc" ; 
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if the intercepted call is external, the line id, together with the 'line type information'. 

• Standard codec negotiation mechanisms shall apply between FP and HPP. The FP shall select the codec used 
between FP and HPP in the {CC-CONNECT} message at the latest. 

• The FP shall notify the PP of the call interception with a {CC-INFO} message containing: 

the HPP CLIP («CALLING PARTY NUMBER » IE); 

the «CALL INFORMATION» IE with the call status 'CS call intercepted' and the same call identifier 
(call identifier of the intercepted call); 

if required by the "Tones provision" feature (see clause 7.4.15.2), the information element «SIGNAL» 
with the value 02H indicating 'Intercept tone on'. 

• The FP shall wait at least a duration of <CC.NG.01> before releasing the call between the FP and the PP with 
a {CC-RELEASE} message. During this period, the FP shall "ignore" the audio received from the PP. 

• The FP shall connect the HPP with a {CC-CONNECT} message. 

NOTE 3: Upon reception of the 'CS call intercepted' call status, the PP may warn the user that the call was 
intercepted (displaying a message, etc.). 

• The FP shall connect the U-plane between the FP and HPP. The peer-to-peer audio path from the remote party 
shall be routed to HPP (instead of PP). 

An example of a successful call interception is given in figure 78. 
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HPP 



PP in a call 

attached with 
line u 



FP 



Remote Party 




Initiated call with call id 1 (internal or external) 



Call interception request 



CC-SETUP 
+ 



« MULTI-KEYPAD, info = '1C 50 2A'H » 
I 

CC-CALL PROC 



« CALL-INFORMATIOM 

< id type = 'Line identifie 

< id type='Line identifier 

< id type/subtype = 'Call 

< id type/subtype = 'Call 
» 



', subtype = 'external", value = 'u'> 
, subtype='line type information', value = 'xy'B > 
dentifier', value = 'call id 1'> 
status', value = 'CS call proc'> 

CC-INFO 



|lf required by the 'Tones provision' feature « SIGNAL = 'Intercept tone on' » 

HPP «CALLING-PARTY-NUMBER» 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier'> 

< Identifier value = 'call id 1 ' > 

< Identifier type/subtype = 'Call status'> 

< Identifier value = 'CS call intercepted'> 

CC-CONNECT 




F<CC.NG.01> 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'call Id 1'> 

< id type/subtype = 'Call status', value = 'CS call connect'> 



1 




call Id 1 Intercepted by HPP 



CC-RELEASE 



CC-RELEASE-COM 




Figure 78: Successful call interception 

NOTE 4: The Call Control message sequence in figure 78 should be understood as an example. The real sequence 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 5: The call interception mechanism may be considered as an automatic call transfer requested by HPP and 
performed by the FP. 

Call interception failure cases: The following cases are distinguished and differ mainly by the tone issued in each case 
by the FP to properly warn the HPP user: 
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Case 1. If the call interception request from the HPP occurs when there is no initiated call on any PP of the DECT 

system: 

• The FP shall consider the request as a standard outgoing call request : the FP shall issue a 
{CC-SETUP_ACK}. If the FP implements a dial tone as described in "Tones provision" feature (see 
clause 7.4.15.2) the FP may send additionally a dial tone (sending of the appropriate IE «SIGNAL» in a 
{CC-INFO}). This warns the user that the line is available. Please note this call has few chances to be 
established as the HPP is very unlikely to send the missing digits. 

• The HPP shall finally release the call with {CC-RELEASE} message (For example upon user hang-up 
request). 

Case 2. If the call interception request from the HPP occurs "too early", before all necessary digits were entered by the 
PP to correctly estabUsh the call with the remote party: 

• The FP, PP and HPP shall however proceed to the call interception as described in the successful case above. 

• The FP should then behave toward the HPP as for a standard PP call when not enough digits are entered. (For 
example by issuing the dial tone nad a busy tone after a certain time). Please note this call has few chances to 
be established as the HPP is very unlikely to send the missing digits. 

• The HPP shall finally release the call with {CC-RELEASE} message. For example upon user hang-up request. 

Case 3. If the call interception request occurs and the 'Call interception' parameter is set to 'Not allowed' in the 'internal 
names' list: 

• The FP shall use the "Busy system or line notification" procedure of clause 7.4.8.3, that is: 

the FP shall send call status 'CS call discormecting' along with call status reason 'control code failed'; 

the FP shall send a «CALL INFORMATION» IE with call status 'CS idle' in order to free the call id 
(on the HPP side only). 

• The HPP shall finally release the call with {CC-RELEASE} message (for example upon user hang-up 
request). 

Specific case with multiple calls or multiples lines feature. 

If the FP implements multiple calls or multiples hues features and a call interception request from the HPP occurs when 
there is more than one active outgoing calls in the DECT system, the behaviour of the system shall be the following: 

• The FP shall issue a «D1SPLAY» message toward the PPs in communications, notifying the user that a call 
interception is requested by the HPP. The sending of the DISPLAY may be restricted to only the PPs attached 
to the same line(s) as the HPP. 

• The first PP to send a "#" keypad will be considered as the intercepted party. This shall be done by the PP by 
sending a control code 23H in a «MULT1-KEYPAD» information element within a {CC-INFO} message. 

• Only upon reception of this keypad, the FP shall then proceed to the call interception of the active call with 
this specific PP as in the successful case. (The call shall be released on PP with prior intercept tone and 
switched to HPP). 

NOTEl: The '#' keypad sending remains compatible with GAP handsets. 

NOTE2: The HPP may release the call at any time. This is also the way to terminate this specific case if none of 
the PP sent the "#" keypad (no need for specific timer in the FP to handle this case). 

NOTE3 : The FP may additionnally support alternative keypad values with equivalent behaviour to "#". (This 

allows an alternative implementation to prevent the very specific case where a second PP accepts the call 
interception after a first one already accepted, and where the "#" keypad would be transmitted over the 
network as standard keypad/DTMF with unexpected effect in the network). 
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Interception of internal calls : 

The FP may support interception of internal calls additionally to interception of external calls. This shall be based on 
the same "#" keypad mechanisms as described in the multiple calls/multiple lines clause above. The first PP which 
invokes the "#" keypad will be considered as the intercepted party. 

7.4. 1 6.3 Headset incoming call 

When receiving an incoming call (external or internal) in the DECT system, the HPP may answer this call using the 
usual incoming call procedures. 

The HPP behaves as a standard PP toward the FP in the DECT system in this case. 

7.4.1 6.4 Re-dial of last outgoing call 

This procedure applies to the HPP and the FP only. 

Upon user request on HPP for re-dialling the last outgoing call: 

• The HPP shall attempt to place a call with a {CC-SETUP} using the 'Normal call setup' basic service. The 
HPP shall not invoke the "Call interception" procedure. 

• The HPP shall access the last entry of the 'outgoing call' list of the FP to retrieve the number of the last 
outgoing call (see 'List access' feature in clause 7.4.10 and annex C for guidelines). 

• If the 'outgoing call' list is available in the FP: 

The HPP shall use this number to fill the «MULTI-KEYPAD» information element sent in a 
{CC-INFO} message. 

The FP shall establish the outgoing call using this number. 

• If the 'outgoing call' list is not available in the FP: 

The FP shall issue a start session confirm with a <Start session reject reason> equal to 'Ust not supported'. 
The HPP may play a negative acknowledgment tone. 

• The HPP shall finally release the call with a {CC-RELEASE} message. For example upon user hang-up 
request. 

NOTE: Re-dialling the last outgoing call is also possible from any registered handset. The HPP may then use the 
regular outgoing call procedure defined in clause 7.4.16.2 and intercept the call. 

If the call can not be estabhshed with the network on the FP side for resources reasons (no line available for example) 
the FP shall notify the HPP with a busy tone as defined in the "Tones provision" feature (see clause 7.4.15.2) 

7.4.1 6.5 Re-dial of last incoming call 

The HPP shall store the CLIP of the last incoming external call. 

Upon user request on HPP for re-dialling the last incoming call, the HPP shall re-use the number included in the CLIP 
of the last incoming external call. 

• The HPP shall attempt to place a call with a {CC-SETUP} using the 'Normal call setup' basic service. The 
HPP shall not invoke the "Call interception" procedure. 

• HPP shall use this number to fiU a «MULTI-KEYPAD» information element sent in a { CC-INFO } 
message. 

• The FP shall estabhsh the outgoing call using this number. 
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If the call can not be established for resources reasons (FP or network reasons) the FP shall notify with a busy tone 
toward the HPP as defined in "Tones provision" feature (see clause 7.4.15.2), using the appropriate «SIGNAL» 
information element. 

7.4.1 6.6 Switching from headset to handset (headset initiated) 

This procedure applies to the FP, the HPP involved in an active call, and any registered PP. It consists in transferring 
the call from the HPP to the PP. 

The HPP shall invoke the call transfer procedure (see clause 7.4.3.6) and more specifically the unannounced call 
transfer procedure (see clause 7.4.3.6.2). 

FP shall support both possible unannounced call transfer requests from HPP: 

• Transfer by calling all PPs: using 2AH as terminal identity number for the internal call. 

• Transfer by calUng one selected PP: using the corresponding terminal identity number for the internal call. 

7.4.1 6.7 Switching from headset to handset (handset initiated) 

This procedure applies to the FP, a HPP involved in an active call and any registered PP. It assumes a call interception 
request can be initiated from the PP via a dedicated MMI. 

The switching is triggered by a user request on the PP. The PP shall invoke the call interception procedure (see 
clause 7.4.16.2.2). 

The call initially active on HPP is "switched" to the intercepting PP. 

7.4.1 6.8 Compatibility with other telephony features and profiles 

Clause 7.4.16.8.1 clarifies the behaviour and limitations of the HPP regarding other features of the present document, 
taking into account that an HPP is considered as a standard PP with however a very limited set of keys. 

7.4.1 6.8.1 Compatibility with other telephony features for a headset portable part (HPP) 

When an HPP is registered on a FP, all the features of the present document apply by default for both parts with status 
defined in clauses 6.2 and 6.4. However, the following restrictions or clarifications also apply : 

Compatibility with Easy PIN code registration [NG1.A.1]: 

This feature is not applicable to HPP except if HPP has keyboard. 
Compatibility witli Easy pairing registration [NG1.A.2]: 
This feature is not applicable to HPP except if HPP has keyboard. 
Compatibility with Missed call notification [NG1.N.3]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of notifications). 
The HPP may support the feature. 

Compatibility with Voice message waiting notification [NG1.N.4]: 

AH procedures are applied on FP side toward the HPP as for a standard PP (sending of notifications). 
The HPP may support the feature. 

Compatibility with Date and time synchronization [NG1.N.5]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of time/date). 
The HPP may support the feature but it is very unlikely. 
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Compatibility with Parallel calls [NG1.N.6] and Common parallel call procedures (external or internal) 
[NG1.N.7]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of notifications). 

It is reconunended that the HPP supports at least "Active call release with replacement (from PP to FP)" of 
clause 7.4.3.5.12. The HPP may support the other procedures but this is unlikely. 

Compatibility with Call transfer (internal or external) [NG1.N.8]: 

The HPP may support the feature. See also procedure" Switching headset to handset (headset initiated)", clause 7.4.16.7. 
Compatibility with 3-party conference call (internal or external) [NG1.N.9]: 

The HPP may participate into a conference call but support of the feature is unlikely (complex to initiate a conference 
from the HPP). 

Compatibility with Intrusion call [NGl.N.lO]: 

The HPP may support implicit or explicit call intrusion. 
Compatibility with Line identification [NG1.N.12]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

The HPP shall support the feature for performing regular calls. 

EXAMPLE: When performing a "regular" external outgoing call, the HPP shall use a line identifier. 

However, when performing a call interception, the HPP shall not send any hne identifier value, nor the 'None' line 
identifier value (see clause 7.4.16.2.2). 

Compatibility with Call identification [NG1.N.13]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 
A HPP shall implement the feature. 
Compatibility with Multiple Imes [NG1.N.14]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

A HPP may implement the feature. The HPP is considered as a standard PP regarding attachment to lines in the line 
settings list. 

Compatibility with Multiple calls [NG1.N.15]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

A HPP may implement the feature. 

Compatibility with List access service [NG1.N.16]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

A HPP may implement the feature and access any of the lists available in the FP. 

Compatibility with the DTMF handlmg feature [NG1.N.19]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

DTMF feature from HPP is unlikely but may be possible if HPP has keyboard. 

Compatibility with Tones provision feature [NG1.N.20]: 

All procedures shall be applied on FP side towards the HPP as for a standard PP. 
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Compatibility with Handling of lines where second calls are signalled in-band feature [NG1.N.22]: 

All procedures shall be applied on FP side towards the HPP as for a standard PP (sending of notifications). 

It is recommended that the HPP supports at least "Active call release with replacement (from PP to FP)" of 
clause 7.4.3.5. 12. The HPP may support the other procedures but this is unlikely. 

Compatibility with Dialled digits (basic) [GAP.N.4]: 

HPP may implement the feature (e.g. shortcut key to request re-dial of last outgoing call or last incoming call). 
Compatibility with internal call feature [GAP.N.31]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 
A HPP may implement the feature and place internal calls. 

7.4.1 6.8.2 Compatibility of a NG-DECT Part 3 lieadset portable part with other profiles 
Behaviour of NG-DECT Part 3 headset registered on a GAP or NG-DECT Part 1 FP: 

• It shall be possible to answer HPP incoming calls as the HPP behaves as a standard PP for incoming call. 

• For outgoing calls possible behaviour of the FP may be the following: 

If the FP supports a "headset management" equivalent feature, the HPP may use it as decribed in the 
present document. 

If the FP supports a "Call intrusion" equivalent feature, the HPP may intrude an outgoing call, if any PP 
is already involved in a call, FP will handle the call intrusion between PP and HPP. 

If internal call transfer is supported by the FP, call will have to be estabhshed on PP first and then 
transferred to the HPP. 

If none of the above features are supported, placing an outgoing call with HPP is not described. 

• With GAP FP, estabhshed calls will only be narrow band calls. 

Behaviour of NG-DECT Part 3 headset registered on a NG-DECT Part 3 FP with a GAP or NG-DECT Part 1 
registered PP: 

The current "headset management" feature applies with the following restrictions: 

• The intercept tone shall be sent in band from FP to PP during outgoing call (instead of out band), (see the 
"Tones provision" procedure in clause 7.4.15.2.2). 

• If the HPP intercepts the call of a GAP PP, the intercepted call (originally in G.726 with GAP PP) may be 
re-negotiated to an other codec between FP and HPP (G.722 for example). 

7.4.17 UTF-8CNIP 

7.4.1 7.1 UTF-8 CNIP sending from the FP to PP 

The sending of the CNIP shall be performed as defined in EN 300 444 [12], clause 8.42 for external call and clause 8.44 
for internal call. Additionally, the following requirements apply: 

An NG PART3 FP shall send the «CALLING PARTY NAME» information element using: 

• UTF-8 encoded characters when the message is sent towards a NG DECT PART3 PP; 

• DECT standard characters as defined in EN 300 175-5 [5], annex D (IA5 characters) when the message is sent 
towards a NG DECT Part 1 or a GAP PP. This implies that the FP translates non 1A5 characters it supports 
into more or less equivalent IA5 characters if they are received in UTF-8 format from the network. 
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NOTE : Use of an IA5 equivalent may be language specific (example: 6 replaced with oe in german), or 
non-language specific (o replaced with o). 

7.4.1 7.2 Display of UTF-8 characters on PP side 

An NG DECT Part 3 PP shall be capable of displaying at least IA5 characters and shall understand UTF-8 encoding 
format (PP shall not misbehave upon reception of UTF-8 encoded characters) 

In addition to IA5 characters, an NG DECT Part 3 PP should be capable of displaying additional UTF-8 characters 
(characters with accents, and symbols for example). The set of supported characters should be in accordance with the 
network the FP is connected to, and may be country and/or language related. Guidehnes for the display of UTF-8 
encoded characters are given in annex M of EN 300 175-5 [5]. 

For UTF-8 characters the PP is not able to display, the PP should use a replacement character. For example, Unicode 
'REPLACEMENT CHARACTER' (code point U+fffd, glyph ❖) could be used for this purpose. This is expected to 
happen when receiving a CNIP from a network in a foreign country (and for which the language is not supported by the 
PP). 

7.5 Data Link Control (DLC) layer procedures 

This clause specifies the additional DLC layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.5.1 DLC services 

The requirements of TS 102 527-1 [21], clause 7.5.1 shall apply. 

7.6 Medium Access Control (MAC) layer procedures 

This clause specifies the additional MAC layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.6.1 MAC services 

The requirements of TS 102 527-1 [21], clause 7.6.1 shall apply. 

7.6.2 Frame formats and multiplexers 

The requirements of TS 102 527-1 [21], clause 7.6.2 shall apply. 

7.6.3 Downlink broadcast 

7.6.3.1 Nt message 

The requirements of TS 102 527-1 [21], clause 7.6.3.1 shall apply. 

7.6.3.2 Qt - static system information 

The requirements of TS 102 527-1 [21], clause 7.6.3.2 shall apply. 
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7.6.3.3 Qt - Fixed Part capabilities 

The requirements of TS 102 527-1 [21], clause 7.6.3.3 shall apply. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 16-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits < a32> to < a^i> of the Qt message. At the 

PT the MAC layer passes the 16 bits out through the ME SAP to the management entity. 
For the setting of the higher layer information bits see clause 7.3.9.1 of TS 102 527-1 [21]. 

7.6.3.4 Qt - Extended Fixed Part capabilities 

The requirements of TS 102 527-1 [21], clause 7.6.3.4 shall apply. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 23-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a25> to <a47> of the Qt message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

No higher layer information for New Generation DECT; parts 1 or 3 is broadcasted in Qt - Extended Fixed part 
capabilities. 

7.6.3.5 Qt - Extended Fixed Part capabilities part 2 



The FT shall be capable of sending and the PT shall be capable of receiving and processing the Qt message as defined 
in EN 300 175-3 [3], clause 7.2.3.11 with the following values. 

Table 74: Values used within Extended FP capabilities part 2 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


«FP capabilities» 


<Qh> 


C 






<a12> 


1 


Long slot j=640 




<a13> 


0,1 


Long slot j=672 (if supported) 




<a23> 


0,1 


"no emission" mode: preferred carrier 
number mode (ON) 



Setting of bit ajj : "no emission mode" 

^23- 1 • variable preferred CN /every CN possible. 

a23 = 0: fixed preferred CN. 

The preferred carrier number is selected and broadcasted by the FT (PT broadcast info). 
FT: 

if (ajj = 1 ), then DummyPointer-wakeups on all carriers should be done after reset; 

if (ajj = ), then DunmiyPointer-wakeup only on the known preferred carrier should be done after reset. 

PT: 

check capability "no emission" mode: preferred carrier number mode; 

if (a23 = 1 ), then DummyRequest-wakeups on all carriers should be done after reset or asynchronous 
mode; 

if (a23 = ), then DummyRequest-wakeup only on the known preferred carrier should be done after reset 
or asynchronous mode. 
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Higher layer information: The management entity in the FP supplies the MAC layer with a 24-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a24> to <a47> of the Qt message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

For the setting of the higher layer information bits see clause 7.4.9.2.2. 

7.6.3.6 Qt - SARI list contents 

The requirements of TS 102 527-1 [21], clause 7.6.3.6 shall apply. 

7.6.4 Paging broadcast 

The requirements of TS 102 527-1 [21], clause 7.6.4 shall apply. 

7.6.5 "no-emission" mode 

The requirements of EN 300 175-3 [3], clauses 7.1.2, 7.2.3.11, 7.2.4.3, 7.3.5.3, 9.4 and 11.11 shaU apply. 

7.7 Physical layer (PHL) requirennents 

7.7.1 Modulation 

The FT and PT shall support 2 level Gaussian Frequency Shift Keying (GFSK) modulation as defined by 
EN 300 175-2 [2], clause 5. 

7.7.2 Slot type (Physical packets) 

The requirements of TS 102 527-1 [21], clause 7.7.2 shall apply. 

7.8 Requirements regarding the speech transmission 

7.8.1 General 

The requirements of TS 102 527-1 [21], clause 7.8.1 shall apply. 

7.8.2 Speech codecs 

The requirements of TS 102 527-1 [21], clause 7.8.2 shall apply. 

7.8.3 Audio performance requirements 

The requirements of TS 102 527-1 [21], clause 7.8.3 shall apply. The status of each feature shall be as defined by 
tables 8 (see clause 6.8) and 2 (see clause 6.3) of the present document. 

7.9 Management procedures 

All procedures described in GAP (EN 300 444 [12], clause 13) shall be supported. Higher layer capability FP broadcast 
shall be set as described in clause 7.4.9.2 of the present document. 

7.10 Application procedures 

This clause specifies the additional application layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 
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7.10.1 Easy PIN code and easy pairing registration 

The "Easy PIN code registration" and "Easy pairing registration" features use common procedures (see clause 7.10.1.3) 
and specific procedures (see clauses 7.10.1.1 and 7.10.1.2 respectively). 



7.10.1.1 Easy PIN code registration 

7.10.1.1.1 Searching mode and PIN code requests 

The access rights procedure triggered by the user on the PP causes it to actively search for a FP broadcasting 'Access 
Rights requests supported' capability bit (Higher layer capabilities bit a^^ = 1 , see EN 300 175-5 [5], clause F. 1 and EN 

300 444 [12], annex A (informative): PP locking procedure for on-air subscription procedure). The searching mode 
shall be limited by the timer P<AP.02>. 

When a FP is found in subscription mode, the PP shall prompt the user to enter the PIN code. After PIN entering, the PP 
shall start the access rights procedure using the PIN code value for the authentication code. 

NOTE 1: When performing easy PIN code registration, it is assumed that the PP is in close proximity to the FP, and 
therefore the PP will receive a stronger signal from that FP. The PP can use RSSI readings to speed-up 

the search for the desired FP. For example: 

1 - Measure the RSSI level on each channel. 



2 - Synchronize on the FP with the highest RSSI value. 

3 - Wait for the a^^ bit to check if it is set. 

4a - If a44 is set, start the access rights procedure. 



4b - If 344 is not set, put the RFPl on a barred list and go to step 2 (or 1) to find other FP. 

NOTE 2: It is recommended to request the PIN code entering after locking to a FP in subscription mode, because 
this procedure may be common with easy pairing search mode request procedure (see clause 7.10.4). 
Nevertheless it can be done before. 

NOTE 3: For security purposes, it is recommended to use a PIN value different from default '0000' value. In this 
case it could be convenient to indicate the device PIN value with a sticker on the FP. It could also be 
recommended to change the PIN value in the user manual. 



; Enter Pin Code 1^- 



PP-NWK PP-MAC FP-MAC 
Qh^^ (Access rights supported=1) 



Use entered ■ 
PIN code as 
authentication 
code 



■<- 



ACCESS-RIGHTS-REQ 



KFY-AI I OOATF 



AUTH-REQUEST 



AUTHENTICATE-REPLY 



ACCESS-RIGHTS-ACCEPT 



.Qh=3 (Access rights supported=0) 



FP-NWK 



^Registration 
mode 



Figure 79: Easy PIN code registration mode 
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7.10.1.2 



Easy pairing registration 



7.10.1.2.1 



Easy pairing registration description 



Easy pairing feature simplifies the registration process by not requesting any PIN code to the user when the PIN code is 
set to default "0000" value. 

When feature is implemented, related procedures shall be valid at first power ON of a non registered handset and at any 
additional further registrations. 

The PP will systematically try to register with the default "0000" PIN code. In case of failure, the PP will automatically 
switch back to the easy PIN code registration feature process and corresponding procedures. 

From security point of view, successful easy pairing is equivalent to default 0000 PIN code registration which is less 
secure than any non 0000 PIN code registration. As a consequence, for easy pairing registration, the user should be 
instructed to monitor the registration user feedback (see clause 7.10.6). 

As additional security and for user convenience it is recommended to use the "Base station name selection" (see 
clause 7.10.7). This allows checking that registration of a PP is ongoing on the correct FP. 

7.10.1.2.2 Base station limited registration mode 

The FP shall have a physical or a logical button to trigger the access rights procedure. 

When the button is pressed on the FP, the FP shall set its broadcasting Access Rights supported attributes' capability bit 
to enable the on air subscription (see clause 7.4.9.1 "Higher layer information in FP broadcast" and EN 300 444 [12] 
clause 13.6 "Broadcast attributes management"). At the same time, the FP shall set the 'Easy pairing registration 
supported' capability bit (see clause 7.6.3.5 "Qt - Extended Fixed Part capabilities part 2"). 

These bits shall be set during timer F<AP.01>. When the access rights procedure is successfully completed, these bits 

shall be cleared. 

For security reasons, the FP shall perform no more than one successful access rights procedure during the subscription 
mode. 



The access rights procedure triggering by the user on the PP causes it to actively search for a FP broadcasting 'Access 
Rights requests supported' capability bit (Higher layer capabilities bit a^^ = 1, see EN 300 175-5 [5] annex F.l and 

EN 300 444 [12], annex A (informative); PP locking procedure for on-air subscription procedure). The searching mode 
shall be limited by the timer P<AP.02>. 

When a FP is found in subscription mode, the PP shall start the access rights procedure using the '0000' value for the 

authentication code. If the FP rejects the access rights, the PP shall prompt the user to enter the PIN code. The PP shall 
then initiate a new access rights request with the same FP using the PIN entered value for the authentication code. 

NOTE: When performing easy pairing registration, it is assumed that the PP is in close proximity to the FP, and 
therefore the PP will receive a stronger signal from that FP. The PP can use RSSI readings to speed-up 
the search for the desired FP. For example: 



1 - Measure the RSSI level on each channel. 

2 - Synchronize on the FP with the highest RSSI value. 

3 - Wait for the bit to check if it is set. 

4a - If a44 is set, start the access rights procedure. 

4b - If a44 is not set, put the RFPI on a barred hst and go to step 2 (or 1) to find other FP. 



7.10.1.2.3 



Searching mode request 
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Figure 80: Easy pairing wlien PIN is set to default '0000' value 
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Figure 81 : Easy pairing when PIN is not set to default '0000' value: switching back to PIN entry 

Backward compatibility management: when a PP is in front of a FP without easy pairing capability, here are three 
possible behaviours of the PP (among several others and left free to implementer): 

1) The PP uses the easy pairing feature, in case of failure, requests the PIN code, exactly as in front of a FP with 
easy pairing. The PP does not take into account the capabihty bit. This means easy pairing feature is always 
used on the PP independently of the FP type. 

2) The PP uses the easy pairing feature but in case of easy pairing failure, the PP uses the capability bit to warn 
the user that re-triggering of the FP registration button might be necessary before using the easy PIN code 
registration feature. This deals with the case where the FP might not remain in registration mode in case the PP 
easy pairing attempt fails (could occur on some GAP FP for example). 
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3) The PP detects the absence of 'easy pairing registration supported' capability bit from the beginning and 

decides not to use the easy pairing feature but to use easy PIN code registration feature instead. This behaviour 
has the drawback not to use easy pairing. So it should be implemented only if behaviour 1 and 2 can not be 
implemented. 

7.1 0.1 .3 Common procedures to easy PIN code and easy pairing 

7.10.1 .3.1 Registration mode automatic access 

When a PP that it is not registered to any FP is powered on, the PP shall start in a mode where the user is directly 
invited to trigger the access rights procedure. Upon user acknowledge, the access right procedure shall start. 

It shall be possible for the user to leave this mode to switch back to idle mode. 

For any further registrations on the PP (additional registration to the initial one), the registration mode should also be 
easily accessible from the user point of view. 

7.10.1 .3.2 Base station name seiection 

This clause applies only to PP with a display capabiUty. 

The FP shall broadcast its name during the subscription mode. The name shall be composed of up to 17 characters to fit 
in a {CLMS-FIXED} message. The name could be set to the manufacturer and model of the phone by default (see 
note 1) and could be changed by the user to a friendly name. 

As soon as a FP with a^^ set to 1 is found within the FP searching process based on the RSSI, the name shall be 
displayed by the PP. 

EXAMPLE I : The PP may display a list of FP names in subscription mode for selection by the user. 

EXAMPLE 2: The PP may display only the selected FP (taking into account the best RSSI indication for 
example). 

The PP will then start the access rights procedure with the selected FP (see clauses 7.10.2 or 7.10.5). The name shall be 
displayed by the PP with the result of the complete registration procedure. 

The FP shall transmit its name information frequently during the subscription mode (i.e. during timer F<AP.01>). At 
least, the first segment of the FP name shall be transmitted within one period of F<AP.03> after the FP capabilities 
infornoation transmission in order to receive it very quickly on PP side. 

NOTE 1: When there are several FP of same type in range in subscription mode, this can be confusing. Therefore, it 
is recommended to set a unique name by default. For a DECT phone, the name could be composed of the 
phone model reference with the two last bytes of RFPI and indicated with a sticker on the FP. For a 
DECT FP integrated within a gateway/PBX, the name could be composed of the gateway/PBX model 
reference with additional unique identifier. 

NOTE 2: The PP should take into account the FPs not supporting the base name broadcasting (e.g. GAP or 

NG-DECT Part 1 base stations). In that case, the PP may display a message like "Unknown" or the RFPI. 

NOTE 3: With this procedure, the overall process to select a base in registration mode is a little bit longer but it 
really improves the security. 
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FP name broadcasting is initiated by including the «NETWORK-Parameter» information element in the 
{CLMS-FIXED} message. The procedure to construct a multi-section {CLMS-FIXED} message shall be performed as 
defined in EN 300 175-5 [5], clause 8.3. 



PT-IWU 



PT 



FT 



FT-IWU 



MNCL_UNIT_DATA-req 



«NETWORK-parameter = 
Device Name» 



Qh=3 (Access rights supported=1 ) 




^ 


MNCL UNIT DATA-req 


CLIVIS-FIXED 
4 


^ — 

«NETWORK-parameter = 
Device Name» 


Address section 




CLIVIS-FiXED 
•4 


F <AP 03> 


Data section 1 


CLMS-FIXED 
< ■ 




Data section 2 




CLMS-FIXED 




^ 

Data section 3 


MNCL UNIT DATA-req 




4 = 

«Name» 


Qh=3 (Access rights supported=0) 
■* 









Registration mode 



Within 
timer 
F<AP01> 




Figure 82: Base station name broadcasting 
Table 75: Values used within the {CLMS-FIXED} message 1^* segment 



Information element 


Field within the 
Information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 




1 


Address section 


«CLIVIS header» 




010B 


IVIultiple sections/Standard 


«Address» 




CFFFH 


Connectionless Group TPUl 


«Protocol 
Discriminator» 


<Second Discrjnninator> 


000001 B 


DECT Information elements coding 


«Length ldentifier» 




Any 


Indicates implicitly the number of data 
sections to follow 



Table 76: Values used within the {CLIVIS-FIXED} message 2"^ segment 



Information element 


Field within the 
Information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 







Data section 


«CLMS header» 




OOOB 


Data section number - (1st) 


«DATA/Fill» 




41 H 


NETWORK parameter (octet 1) 






Any < 20 


Length (octet 2) 






00010000B 


Discriminator: Device name (octet 3) 






Name 


First character of name (octet 4) 
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Table 77: Values used within the {CLMS-FIXED} message k segment 



Information element 


Field within tlie 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 







Data section 


«CLMS header» 




K 


Data segment (k+1) 


«DATA/Fill» 




Name 








Name/Fill 








Name/Fill 








Name/Fill 





7.10.1.3.3 Registration user feedback 

This clause applies only to FP with user signalling capability (for example a display, a LED or a buzzer). To improve 
the security, it is strongly recommended to support this feature both on the FP and the PP. 

The FP and the PP shall give a feedback to the user of the registration process through a user interface. 

The feedback given on the user interface of the PP and the FP shall be as a minimum the following status of the 
registration process with the following states: 

• Registration in progress state: 

Condition of entrance: the PP is looking for or is locked on a FP in subscription mode and the protocol is 
exchanging messages. 

Recommended user action: wait for protocol to finish. 

• Registration error state: 

Condition of entrance: some error occurred, such as failed to find a peer device, or to complete the access 
rights procedure (e.g. authentication failed). 

Recommended user action: wait then try again. 

• Registration success state: 

Condition of entrance: protocol procedure is complete and successful. 

Recommended user action: try to make an outgoing call request. 

The proposed user feedback with corresponding user interface allows user to check that registration on the correct FP 
was successful. This is an additional secmty especially in the case of the easy pairing procedure which is less secure 
than the PIN code registration procedure. 

The user should be aware that during the registration mode unwanted PP could join the FT*. The user should be 
instructed to monitor the user interface, especially to check the success indication on both sides for security 
considerations. This verification will prevent the PP from joining a FP that was not selected or to prevent an other PP 
from joining the selected FP. 

Type of user interface is left free to implementers. For example, the user interface could be a display on the PP side and 
a LED on the FP side. It could also be an audio tone indication or any other richer user interface (displays on both sides 
for example). 

7.10.2 Handset locator 

On FP side, a software or hardware button shall trigger this procedure. 

The FP shall present an incoming external call to all idle PPs registered to the FP. Incoming call used at NWK level is 
the GAP NWK feature N8 "Incoming call". The FP shall send the information element «Calling Party Name» with 
the <Presentation indicator> field set to 'Handset locator' value. 

On PP side, the call shall be presented as an incoming call. If PP has ringing capabilities enabled, the PP shall ring. 
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NOTE 1: It is recommended that the FP sends a CNIP with a name related to the current procedure, for example 

"Handset locator". 

NOTE 2: The 'Handset locator' value of <Presentation indicator> field in CNIP might be used by the PP to trigger 
the ringing even if it is disabled, or to increase the ringer volume in that particular case. 



Table 78: Values used within the {CC-SETUP} or {CC-INFO} message 
for handset locator internal call CNIP 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
name» 








<Presentation indicator> 


11 


Handset locator 


<Used Alphabet> 


All 




<Screening indicator> 


All 




<Calling party name> 


All 


'Handset locator' for example 



The procedure is stopped when incoming call is accepted by one of the PPs. In this case, the FP shall immediately 
release the call on this particular PP and stops incoming call presentation to other PPs. 

NOTE 3: Other possible stops of the procedure are out of the scope of the present document. For example the 
procedure could also be stopped: 

■ by pressing the button again on the FP side; 

■ by using a timer mechanism on FP side. 

NOTE 4: The way the call is accepted on the PP is out of the scope of the present document. For example only the 
call key could accept the incoming call. 





CC-SETUP «CNIP=Hanset locator» 


4 

CC-SETUP «CNIP=Hanset locator» 


M 

PP1 is loci 


ted by user 
CC-CONNECT 


» 

CC-RELEASE 


4 

CC-RELEASE-COM 
¥ 


CC-RELEASE 


< 





Figure 83: Handset locator example where PP1 is located 

NOTE 5: The Call Control message sequence in figure 83 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

If one of the registered PPs is already involved in a call, the FP shall either: 

• Apply the current procedure to idle PPs only and leave the PP involved in its call. 

• Wait for all PPs to be in idle state before applying the current procedure to all PPs. 
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NOTE 6: If an incoming call occurs while the handset locator procedure is already ongoing, the FP should stop the 
handset locator call and present the incoming call. 
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Annex A (normative): 
System parameters 

A.1 CC timers 

<CC.NG.01> Intercept tone provision timer. 
FT value: 1 300 milliseconds. 

PT value: Not used. 

Start: A «SIGNAL» IE has been sent requesting a tone generation. 

Stop: none. 

NOTE : The 1 300 milliseconds value is compatible with the value defined by ITU-T Recommendation 
E.180 [i.lO], specification for the special information tone. 



A.2 Application timers 



<AP.01> Subscription mode timer. 

FT value: 120 seconds. 

PT value: Not used. 

Start: Subscription mode has been requested by the user and bit a^^ of "higher layer capabilities", 

"access rights supported", has been set. 

Stop: As soon as on-air subscription procedure is successful and bit a^^ of "higher layer capabiUties", 

"access rights supported", is cleared. 

<AP.02> Searching mode timer. 

FT value: Not used. 

PT value: 120 seconds. 

Start: Searching mode has been requested by the user: hsten and wait for bit a^^ of "higher layer 

capabilities", "access rights supported". 

Stop: As soon a as on-air subscription procedure is successful. 

<AP.03> Base station name broadcasting timer. 

FT value: 160 ms. 

PT value: Not used. 

Start: Base station name broadcasting occurrence (Higher layer capabilities FP broadcast sent). 

Stop: The first segment of the FP name is sent. 



ETSI 



244 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



Annex B (normative): 
Procedure diagrams 

The following diagrams depict basic sequences that illustrate the text of present document. 

The Call Control message sequences in the following diagrams shall be understood as examples. The sequences may 
also contain different Call Control messages or Call Control messages in another order or Call Control messages with 
other contents. 

EXAMPLE: {CC-ALERTING} and {CC-CALL PROC} are sometimes not mentioned although they are 
allowed in the sequences. 



B.1 Events notification diagrams 

The following flowcharts are very basic sequences. See also annex C (especially clauses C.2.4 and C.2.5) for more 
complete examples of notifications. 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that must convey it. Please note that they should not be omitted when implementing 
equivalent cases. 

B.1 .1 Event notification when there is no existing connection 

Use case: FP wants to send an event notification and there is no existing cormection: use the CLSS procedure (page the 
PP and setup the bearer). 



PP 



FP 



NWK MAC 



MAC NWK 
LCE-REQUEST-PAGE 



access_request 



bearer confirm 



FACILITY 



«EVENTS NOTIFICATION», 
«CALL-INFORMATION, Lineld» 



Figure B.1 : Event notification wlien tliere is no existing connection 

NOTE: Line identifier may be equal to 'all lines' value. 



ETSI 



245 ETSI TS 1 02 527-3 V1 .2.1 (201 0-04) 

B.1 .2 Event notification during existing connection 

Use case: FP wants to send an event notification when the PP is on communication: use the existing connection. 



pp 




FP 






FACILITY 






■< 


«EVENTS NOTIFICATION», 
«CALL-INFORMATION, Lineld» 













Figure B.2: Event notification during existing connection 

NOTE: Line identifier may be equal to 'all lines' value. 

B.1 .3 Event notification when tlie PP is switclied on 

Use case: FP has wanted to send an event notification when PP was switched off, PP is switched on: use the location 
registration connection. 



PP 




FP 




LOCATE-REQUEST 










LOCATE-ACCEPT 






■< 


FACILITY 








•< 


«EVENTS NOTIFICATION» 








«CALL-INFORMATION, Lineld» 





Figure B.3: Event notification when the PP is switched on 



NOTE: Line identifier may be equal to 'all lines' value. 
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B.1 .4 Event notification using call connection 

Use case: FP has wanted to send an event notification when PP was not in range, PP sends a {CC-SETUP}: use the call 
connection. 



PP 



FP 



CC-SETUP 





► 

CC-CONNECT 


•< 


FACILITY 


< 





«EVENTS NOTIFICATION», 
«CALL-INFORMATION, Lineld» i 



Figure B.4: Event notification using call connection 

NOTE: Line identifier may be equal to 'all lines' value. 

B.1 .5 Event notification for "IVIissed call notification" 

Use case: Missed call notification message sequence. 



PP 



Alerting 



User accesses 
missed caiis iist 



FP 



CC-SETUP 



« CLIP » 



CC-ALERTING 



CC-RELEASE 



RELEASE REASON, 



CC-RELEASE-COM 



« RELEASE REASON » 



FACILITY 



« EVENTS NOTI FICATIONS, < Missed call, Voice, 1 >, 
< List change indication, Missed call list, 1 > » 
« CALL-INFORMATION », Linedid » 



End of incoming caii 



Missed calls list consultation using list access feature 
(Read or edit command) 



FACILITY 



« EVENTS NOTIFICATIONS, <Missed call. Voice, > » 
« CALL-INFORMATION, Lineld » 



Figure B.5: Missed caii notification 



NOTE: See also clause C.2.4 for more detailed flowcharts including line identifiers and call identifiers. 
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B.2 Date-time synchronization diagrams 

These flowcharts depicts the date and time synchronization feature, but only in the cases where the FP sets the date and 
time of the PP. When implementing this feature, the FP behaviour shall follow one of the possible use cases listed 
hereafter. Please note some flexibihty is allowed concerning the CC messages. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that must convey it. Please note that it should not be omitted when implementing equivalent cases. 

EXAMPLE: The call identifier must be assigned by the FP after {CC-SETUP} message. 



B.2.1 Date-time synchronization when there is no existing 
connection 

Use case: FP wants to send a time and date synchronization and there is no existing connection: use the CLSS 
procedure (page the PP and setup the bearer). 



PP 



FP 



NWK MAC 



I 

MAC NWK 
LCE-REQUEST-PAGE 



access_request 



bearer confirm 



FACILITY «Time-Date » 



Figure B.6: Date-time synclironization wlien tliere is no existing connection 



B.2. 2 Date-time synchronization during existing connection 

Use case: FP wants to send a time and date synchronization when the PP is on communication : use the existing 
connection. 



PP 



FP 



FACILITY « Time-Date » 



Figure B.7: Date-time synclironization during existing connection 
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B.2.3 Date-time synchronization when the PP is switched on 

Use case: FP has wanted to send a time and date synchronization when PP was switched off, PP is switched on : use the 
location registration connection. 



PP 


FP 




LOCATE-REQUEST 




LOCATE-ACCEPT 


^ FACILITY « Time-Date » 









Figure B.8: Date-time synclironization wlien tlie PP is switclied on 

B.2.4 Date-time synchronization using call connection 

Use case: FP has wanted to send a time and date synchronization when PP was not in range, PP sends a {CC-SETUP} : 
use the call connection. 



PP 




FP 




CC-SETUP 








■< 


CC-CONNECT 






< 


FACILITY « Time-Date 


» 





















Figure B.9: Date-time synclironization using call connection 

NOTE: The line identifier is not represented here. Note that it is anyway only relevant if the synchronization is 
done in the context of an external call. 

B.3 List access service basic sequence diagrams 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that must convey it. Please note that they should not be omitted when implementing 
equivalent cases. 



ETSI 



249 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



B.3.1 Start/end session when PP is in idle mode 



PT 



FT 



Direct PT initiated linl< establishment 



CC-SETUP 



IE « Basic Service < Call Class= LiA service call setup > » 
CC-CALL-PROC 



IWU-lnfo 



IE « IWU to IWU= start session, list identifier, sorting field identifiers » 

IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier. Total number, 
sorting field identifiers » 



list access 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-RELEASE 



CC-RELEASE-COM 



Figure B.10: List access: start/end session wlien PP is in idle mode 
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B.3.2 Start/end session when a call is already established to PP 



PT 



FT 



call established 



IWU-lnfo 



IE « IWU to IWU= start session, list Identifier, sorting field Identifiers » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session Identifier, Total number, 
sorting field identifiers » 



list access 



IWU-lnfo 



IE « IWU to IWU= end session, session Identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session Identifier » 

Figure B.11 : List access: start/end session wlien a call is already established to PP 

NOTE: See also diagrams in clause C.6 for examples on list access and voice calls flowcharts. 



B.3.3 Query supported entry fields 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= query supported entry fields, session identifier » 



IWU-lnfo 



IE « IWU to IWU= query supported entry fields confirm, session Identifier, list 
of supported entry field ldentlflers» 



Figure B.I 2: List access: query supported entry fields 
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B.3.4 Read entries 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, start index, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.13: List access: read entries 
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B.3.5 Edit entry 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= edit entry, session id, entry identifier, list of field identifiers » 



IWU-lnfo 



IE « IWU to IWU= edit entry confirm, session id » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.I 4: List access: edit entry 
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B.3.6 Save entry 



PT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= save entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part k » 



IWU-lnfo 



IE « IWU to IWU= save entry confirm, session id, start index, 
entry identifier, position index » 

FACILIPk' (optional, depending on list) 



FT 



« EVENTS NOTIFICATION, List change notification », 
« CALL INFORMATION, Line Id » 



Figure B.15: List access: save entry 

NOTE: Alternatively the {FACILITY} message might be sent after terminating the list access session. 



B.3.7 Delete entry 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= delete entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= delete entry confirm, session id, total numb 



Figure B.I 6: List access: deiete entry 

NOTE: The list has changed once this procedure has been performed. PP should read list again starting from 
index of the first entry which was deleted. 
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B.3.8 Delete list 



PT 



FT 



list access sesion 

Call id=l, call status = 'CS call connect' 
Call id=2, call status = 'CS call hold' 



IWU-lnfo 



IE « IWU to IWU= delete list, session id » 



IWU-lnfo 



IE « IWU to IWU= delete list confirm, session id » 



Figure B.I 7: List access: delete list 



B.3.9 Search entries 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= search entries, session id, searched value, counter, list of 

field identifiers » 



IWU-lnfo 



IE « IWU to IWU= search entries confirm, session id, start index, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.I 8: List access: searcli entries 
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Annex C (informative): 

Recommended implementation of procedures 
C.1 General 

In the following clauses, several examples for generic sequence charts are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows are always 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperabihty. 



C.2 Multiple lines diagrams 

The diagrams of this clause document the "Multiple lines" feature. This feature can be used when at least the FP 
implements it. For the PP, implementing this feature means that it is aware of multiple attachments, and proposes an 
adapted MMl. 

However a PP may be attached to several lines without being aware of it, i.e. not implementing the "Multiple lines" 
feature. Such a PP would use e.g. "FP-managed line selection" (see clause 7.4.5.2.4) for outgoing calls, and would 
receive calls from these lines at the price for the user of not knowing from which line an incoming call arrives (unless 
asking the calling user). 

The "Line identification" feature is a pre-requisite for the 'Multiple lines' feature on PP side and on FP side. This feature 
allows the user to place a call on line k by keyboarding '#k' before the called number, or by introducing the 'k' value 
through a dedicated MMI. It also allows the user to know in advance on which line a call is received through the 
display. With the "Line identification" feature alone, the PP still would not be able to propose a menu with the set of 
attached Unes presented and to choose from. 

C.2.1 Attaching a new PP to one or several lines 

Use case: the user hast just registered a new PP, then the user is invited to select the line(s) to which the new PP is 
attached to (PP managed attachment). This use case can also be used later to change the handsets attachment to the 
lines. 

We assume that the new registered PP is the terminal number 'm'. 
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PP FP 

ACCESS-RIGHTS-REQUEST 



-> 



ACCESS-RIGHTS-ACCEPT 



LOCATE-REQUEST 



LOCATE-ACCEPT 



TEMPORARY-IDENDITY-ASSIGN-ACK < TPUl ldN=m > 



Line settings start session. 'Total number of entries' = N (lines) 




for(ne 1.. N) 



handsets' field of each line for the new registered PP: 

IWU-INFO 



IE « IWU to IWU= read entries, session id, start index=n, counte r=forward/1 , 
list of field identifiers = Line Id id. Line name id. Attached handsets id » 

IWU-INFO 



IE « IWU to IWU= read entries confirm, session id, counter=1 » 
IWU-INFO 



IE « IWU to IWU= data packet, session id, content part = n* entry content » 

IWU-INFO 



IE « IWU to IWU= edit entry, session id, entry identifier = entry id n, 
list of field identifiers= Line Id id, Line name id. Attached handsets id » 

IWU-INFO 



IE « IWU to IWU= edit entry confirm, session id, start index = n » 

IWU-INFO 



IE « IWU to IWU= data packet last, session id, content part= n* entry content » 



user may update the 'Attached handsets' field for n* line in line settings list 
to attach the new registered PP to the n* line 



IWU-INFO 



IE « IWU to IWU= save entry, session id, entry identifier= entry id n » 
IWU-INFO 



IE « IWU to IWU= data packet last, session id, content part= n* entry updated » 

IWU-INFO 



IE « IWU to IWU= save entry confirm, session id, entry identifier = entry id n, 



FP notifies list change notification to all PPs attached to the line n 



line settings end session 



Figure C.I : Attaching a new PP to one or several lines 

NOTE 1: The above diagram assumes that only one "data packet" command is necessary for reading one entry 
content, i.e. the 'data packet last' command is received directly. 

NOTE 2: As an alternative, all entries in the "Line settings" list could be read all at once with one read entries 
command. 



ETSI 



257 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



C.2.2 Outgoing first call on a line 

For each use case, two sub use cases at least are handled: Line identification by PP, or FP managed line selection. 

C.2.2.1 PP attached to 1 line 

See below, clauses C.2.2.2.1 and C.2. 2.2.2, as there is no difference from the case when a PP is attached to several lines 
(the only hne-id still must be sent at call setup by a PP attached to only one line). 

C. 2.2.2 PP attached to several lines 

Clauses C.2.2.2. 1 and C. 2.2.2.2 implement variants of the same use case: the PP implements the "Line identification" 
feature and sends the Une-id when setting up the call. 



C.2.2.2.1 Line identification by PP using «CALL-INFORMATION» 

Use case 1: the PP selects a line on a call-by-call basis using «CALL-INFORMATION» IE. 

PP FP Network 

CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 



Use of line u 
for calling 
'called number' 




Figure 0.2: Line identification by PP using «CALL-INF0RIU1ATI0N» 

NOTE : As "Call identification" is mandatory for NG PART3, The call identifier notification is represented, 

although it is somehow independent of the "Multiple lines" feature. The line identifier value is repeated in 
the «CALL INF0RMAT10N» IE together with the indication of the 'hne type information'. 

C.2.2.2.2 Line identification by PP using the «MULTI-KEYPAD» 

Use case: the PP selects a line on a call-by-call basis using « MULTI-KEYPAD » IE (e.g. the user used the keyboard 
to select the hne instead of the dedicated MMI). 
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PP 

attached to line u e 1..9 



FP 



Network 



CC-SETUP 



« MULTI-KEYPAD, < Keypad info = '23 3u'H > » 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD, < Kevoad info = 'called number' : 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 



Use of line u 
for calling 
'called number' 




Figure C.3: Line identification by PP using «IU1ULTI-KEYPAD» 



NOTE 1: Restriction to [0..9] interval for the line id value is in place here because «MULTI-KEYPAD» is used 
for sending the Une id. 

NOTE 2: As "Call identification" is mandatory for Part 3 FPs, the call identifier notification is represented, 

although it is somehow independent of the "Multiple hues" feature. The line identifier value is repeated in 
the «CALL INFORMATION» IE together with the indication of the line type information. 

C.2.3 First incoming call on a line 
C.2.3.1 PP attached to 1 line 

See below, clause C.2.3 .2, PP attached to several lines, as there is no difference with the case when a PP is attached to 
several lines. 
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.2.3.2 PP attached to several lines 

case: the PP is attached to several Unes. An incoming call on Une u is presented. 



PP 

attached at least to 
line u 



CC-SETUP 



« CALL-INFORMATION, 



Identi 
Ident 
Ident 
Identi 
Ident 
Identi 
Identi 
Identi 
Ident 
Identi 



fier type = 'Line identifier' > 

tier subtype = 'Line identifier for external calls' 

fier value = u > 

fier type = 'Line identifier' > 

fier subtype = 'line type information' > 

fier value = 'xy'B > 

fier type/subtype = 'Call identifier' > 

fier value = = 'call-id 1' > 

fier type/subtype = 'Call status' > 

fier value = 'CS call setup' > 




Network 



Incoming call to line u 
from 'calling number' 



Figure C.4: First incoming call, PP attached to several lines 
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C.2.4 Missed call 

Use case: An incoming call on line u is not answered, and there are already two 'unread' missed calls in the list. The PP 
is attached to one or several lines. A 'list change indication' for the 'missed call list' is sent together with the 'missed call 
notification' (see clause 7.4.1.3, 'simultaneous Ust change indication' subsection). The 'missed call notification' and 
related 'list change indication' are sent in this example just after the incoming call release. 

PP 

attached at least to 
line u 

CC-SETUP 

< 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup' > 

» 

CC-RELEASE 



CC-RELEASE-COM 



FACILITY 

< 

« EVENTS-NOTIFICATION, 

< Event type = 'Missed call' > , 

< Event sub type = 'A new external missed voice call 
just arrived' > 

< Event multiplicity = 3 > < 

< Event type = 'List change indication' > , 

< Event sub type = 'Missed call list' > 

< Event multiplicity = 'number of missed called in the 
missed calls list' for the specified line> 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = Line identifier for external call' > 

< Identifier value = u > 

» 



Figure C.5: iUlissed call 

NOTE: The list change indication for the Missed call list accompanying the 'missed call notification' is 
mandatory. 



FP Networic 



Incoming call to line u 
from 'calling number' 




TFere are 3 'unread' 
missed calls relating J 
the specified line in th^ 

Iissed call 
^ding thl^H 
jgering this 
tification 
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C.2.5 Voice message waiting indication on a specific line 

Use case: a voice message has been left in the voice mailbox of line 'u' which already contained one message, a voice 
message wailing indication is sent to each PP attached to this line. For this network, the 'number of messages' notified 
corresponds to the total number of messages in the voicemail box (see clause 7.4.1.2). 

PP 

attached at least to 

line u FP Network 



FACILITY 


y\ 1 

Voice message waiting 
indication on line u 






« EVENTS-NOTIFICATION, 

< Event type - 'Message waiting'>, 

< Event sub type = 'Voice' > 

< Event multiplicity = 2 >M 

<< CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Relating-to line identifier' 

< Identifier value = u > 

» 




There are 2 messages remaining in 
the voicemail box of the SDecified 
line , including the new one 
triggering this notification 









Figure C.6: Voice message waiting indication on a specific line 



C.2.6 IVIissed call notification scenario 

Use case: The following Ust of incoming calls and other events occurs. None of the incoming calls has been answered. 

1) Incoming external call on Une 1 (clause C.2.6. 1). 

2) Two incoming extemal call on line 2 almost simultaneously (clause C.2.6. 2). 

3) Incoming internal call (clause C.2.6. 3). 

4) Incoming external call on hne 1 (clause C.2.6.4). 

5) A PP reads one of the two 'unread' entries for line 1 in the missed call list (clause C.2.6. 5). 

6) A PP reads the remaining 'unread' entry for Une 1, and a missed call arrives on line 1 almost simultaneously 
(clause C.2.6. 6). 
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C.2.6.1 After call on line 1 



Table C.1 : Missed call list related notifications after event 1 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 


1 


A new external missed voice call just 

arrived 




<Event multiplicity > 


1 


Number of new missed call in the 
missed call list for the specified line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed calls list 




<Event multiplicity > 


1 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


1 


The line identifier value itself 



The <Event multiplicity> field for the 'list change indication' gives the total number of entries in the 'missed call list', 
that is, the number of all ('unread' and 'read') missed calls, but for the line indicated in the «CaIl information» IE 
only, NOT for all lines. 

C.2.6. 2 After two almost simultaneous calls on line 2 

Here two events of the same type occur on the same hne 2 almost simultaneously, and are notified together (see 
clause 7.4.1.3, 'Almost simultaneous events'). 



Table C.2: Example IVIissed call list related notifications after event 2 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


1 


Missed call 


<Event sub type> 


1 


A new external missed voice call just 
arrived 


<Event multiplicity > 


2 


Number of new missed call in the 
missed call list for the specified line. 


<Event type> 


3 


List change indication 


<Event sub type> 


1 


Missed calls list 


<Event multiplicity > 


2 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier typo 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


2 


The line identifier value itself 



The 'Total number of elements in the hst for the specified hne' only counts elements for hne 2, and therefore does not 
take into account the first missed call (see clause C.2.6.1) which was on line 1. 

C.2.6.3 After incoming internal call 

Internal missed calls are not placed in the 'missed call Ust', and no notification is sent. 
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C.2.6.4 After call on line 1 



Table C.3: Missed call list related notifications after event 4 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 


1 


A new external missed voice call just 

arrived 




<Event multiplicity > 


2 


Number of new missed call in the 
missed call list for the specified line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed calls list 




<Event multiplicity > 


2 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


1 


The line identifier value itself 



C.2.6.5 A PP reads one of the two 'unread' entries for line 1 in the missed 
call list 

Here there is no new missed call, but still a 'missed call notification' for updating the number of new missed calls. 
Absence of a new missed call is indicated through the use of subtype '02'H. 

Table C.4: Missed call list related notifications after event 5 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 


2 


No new missed call arrived, but the 
number of 'unread' external missed 
voice calls has-or may have-changed 




<Event multiplicity > 


1 


Number of new missed call in the 
missed call list for the specified line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed calls list 




<Event multiplicity > 


2 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


1 


The line identifier value itself 



C.2.6.6 A PP reads the remaining 'unread' entry for line 1 , and a missed call 
arrives on line 1 almost simultaneously 

Here two events of different types occur on the same line 1 almost simultaneously, and are notified together (see 
clause 7.4.1.3, 'Almost simultaneous events'). 

Subtype 'Ol'H ('New external missed call') is used, as one of the events is the arrival of a new missed call (see 
clause 7.4.1.3, 'Almost simultaneous events', rule 3). 

However, the total number of 'unread' missed calls does not change, as the other event (of type 'Entry modified') 
decreases the number of 'unread' entries in the missed call list by one. 
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NOTE: If the two events had been notified separately, the notifications would have used different 'missed call 

subtypes'. 



Table C.5: Missed call list related notifications after event 6 (see clause C.2.6) 



Information element 


Field within tlie information 
element 


Standard values 
witnm the tield/lc 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 




A new external missed voice call just 
arrived 




<Event multiplicity > 


1 


Number of new missed call In the 
missed call list for the specified line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed calls list 




<Event multiplicity > 


3 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier valu8> 


1 


The line identifier value itself 



C.3 Multiple calls diagrams 

C.3.1 First incoming call on the line or system 

Use case: the PP is attached to a multi-call line. An incoming call is presented to the line. 



PP 

attached to 
multiple-call line u 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



fler type = 'Line Identifier' > 
fler subtype = 'Line identifier for external calls' 
fler value = u > 
ifier type = 'Line Identifier' > 
ifier subtype = 'line type Information' > 
fler value = 'xy'B > 
fler type/subtype = 'Call identifier' > 
fler value = 'call-id 1'> 
ifier type/subtype = 'call status' > 
fler value = 'CS call setup' > 




Incoming call from 
'calling number' 



Figure C.7: First incoming call on the line or system 



NOTE: Although somehow independent of the "Call identification" feature, the line identifier notification is also 
represented, as "Line identification" is mandatory for Part 3 FPs. 
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C.3.2 Second incoming call on the line or system 

Use case: the PPs are attached to a multi-call line. A call is going on from PPl. An incoming call is presented to the 
line. For conciseness of the diagram, line identification is not represented (which corresponds to the case of an internal 
waiting call). 
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PP2 

attached to line u 



PP1 

attached to line u 



FP 



Network 



Incoming call 
presentation 



Call established with call Id 1 (external or internal) 



CC-SETUP 



i- 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2 > 

< id type/subtype = 'Call status', value = 'CS call setup' 

CC-INFO 



Call waiting 
indication 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2 > 

< id type/subtype = 'Call status', value = 'CS c all setup' > 



If PP2 accepts the c ajJI^(or ac cepts it first) 

CC-CONNECT 



I 

CC-CONNECT-ACK 



CC-INFO 



« CALL-INFORMATllON 

< id type/subtype 

< id type/subtype 



Call identifier', value = 2> 
Call status', value = 'CS call connect'> 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2> 

< id type/subtype = 'Call status', value = 'CS idle': 



If PP1 acceots the (waitina) call (or acceots it first) 



CC-INFO 



« MULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2> 
CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 1> 

< id type/subtype = 'Call status', value = 'CS cjll hold's 

.» CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2> 

< id type/subtype = 'Call status', value = 'CS c 



CC-RELEASE 



T 

CC-RELEASE-COM 



ncoming call from 
'calling number' 



ill connect'> 



Figure C.8: Second incoming call on the line or system 
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C.3.3 First outgoing call on the line or system 

Use case: the PP is attached to a multi-call line. An outgoing call is initiated. 



PP 

attached to 
a multiple-call line 'u' 



CC-SETUP 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



FP 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Network 



Use of line u 
for calling 

'called number' 




Figure C.9: First outgoing call on the line or system 



NOTE: Figure C.9 does not show the exchange of line identifiers. For a complete diagram, see for example 
clause C.2.2.2.1. 
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C.3.4 Second outgoing call on the line or system 

Use case: the PPs are attached to a multi-call line. A call is going on on PPl. A second external call is initiated. For 
conciseness of the diagram, line identification is not represented (which corresponds to the case of an internal outgoing 
call). 



PP2 

attached to line u 



PP1 

attached to line u 



FP 



Network 



Call established with call Id 1 (external or internal) 



ulf second call is 
|lnltlated by the PP2 



CC-SETUP 



t 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 
» 

GG-INFO 
-t- 



Use of line u (if 
external) for calling 
'called number' 





« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATiON, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call Id 2' > » 



if second call is 
initiated by the PPl 



CC-INFO 




« MULTI-KEYPAD, < Keypad info = '1C15'H > > 
CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 




Use of line u (if 
external) for calling 
'called number' 




« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



Figure C.10: Second outgoing call on the line or system 
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C.4 Parallel calls complex or alternative diagrams 

This annex illustrates use cases of the "Conomon parallel call procedures" feature [NG1.N.7] that are not described in 
the main part of the standard (see figures of clause 7.4.3.5) but require clarification, and gives guidelines for 
implementation. More specifically, it includes: 

• Alternative use cases. 

• Limit or complex use cases that may not happen so often but illustrate the philosophy of the standardized 
procedures. 

NOTE: Clauses C.2 and C.3 deal with "Multiple lines" and "Multiple calls" specific use cases (e.g. not applicable 
in the PSTN double call case). 

C.4.1 Call identification for outgoing parallel calls 

This clause shows variants of the "Outgoing parallel call initiation" diagrams presented in the procedure itself (see 
clause 7.4.3.5.1), that correspond to variant use cases. In all the diagrams presented, the call-id is sent by the FP as soon 
as possible, (and even if the line-id is not known at this stage) so that it can be used by the PP in all subsequent 
messages concerning that call (for messages that use the call id when available). 

C.4.1 .1 All in one PP message - line identification by PP 

Use case: The PP sends all parallel call initiation information in a single {CC-INFO} message (e.g. the user used the 
phone book before placing a parallel call). A single message sent by the PP with '1C15'H / '17'H + line-id + called- 
number. 
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PP ^ ^ FP 





<:::;;;;;;|]^^^^ call (external or internal) with call id 




Outaoina call initiation includina line : 


election bv the PP (not FP-manaaed) 


>: 




Line selected for the call (if external), 
by an NG-DECT Part 3 PP using the 
GALL-INFO method 

OR 

Line selected for the call (if external) 
by a GAP.an NG-DECT Part 1 , or, 
possibly, an NG-DECT Part 3 PP, 
using the KEYPAD method 




CC-INFO 


► 

« MULTI-KEYPAD, < Keypad info = 1C15 H/17 H -i- called number > 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > » 

CC-INFO 


► 

« MULTI-KEYPAD, < Keypad info = '1C15'H / '17'H + '23 3u'H -i- 
'called number'> » 




^ CC-INFO 




« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01' H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 


Call id assianement bv the FP 


CC-INFO 




Line identifier is only sent to NG- 
DECT Part 3 PPs 


« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

< id type/subtype = 'Call status', value = 'CS call proc' > 
» 









Figure C.11: Outgoing parallel calls: all in one PP message, line identification by PP 



C.4.1 .2 All in one PP message - FP-manage(d line selection 

Use case: The PP sends all parallel call initiation information in a single {CC-INFO} message (e.g. the user used the 
phone book before placing a parallel call). However, "FP-managed line selection" (see clause 7.4.5.2.4) is used. A 
single message sent by the PP with 'ICIS'H / '17'H + called-number, but with the special line-id value 'None'. 
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Outgoing call initiation with FP-managed line selection 






Outgoing 
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CC-INFO 




► 

« MULTI-KEYPAD, < Keypad info = '1C15'H / '17'H > 

< Keypad info = 'called number' > » 
« CALL-INFORMATION 

< id type = 'Line identifier', subtype = 'external call' > 
value = 'None' > 

» 






CC-INFO 




« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01' H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 




Call id assignement and 
line selection by the FP 






CC-INFO 




1 « CALL-INFORMATION, 


Line selection performed 
■ by the FP 


< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information'. 






value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

< id type/subtype = 'Call status', value = 'CS call proc' > 







Figure C.12: Outgoing parallel calls: all in one PP message, FP managed line selection 



C.4.1 .3 Line pre-selection by PP - Manual dialling of called number 

Use case: The PP initiates a parallel call with 'ICIS'H / '17'H + line-id in a single {CC-INFO} message (e.g. the user 
pre-selected or pre-diaUed ('#k') the line to use-unless the PP is attached to only one line, in which case the user does 
not have to do so, but the present use case still applies-before manually dialling the called number). The FP replies with 
the call-id as soon as it received the first message, and before dialUng of the called number. 
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(possibly) an NG-DECT Part 3 PP 
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« MULTI-KEYPAD, < Keypad info = '1C15'H/'17'H -i- 'called number' > >> 

« CALL-INFORMATION, 
< id type = 'Line identifier', subtype = 'external call', value = 'u' > » 

CC-INFO 


► 

« MULTI-KEYPAD, < Keypad info = '1 C1 5'H / '1 7'H -i- '23 3u'H -i- 
'called number' > 




CC-INFO 


« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01' H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 




Call Id asslgnement by the FP 

— Line identifier is only sent to NG- 
BIdECT Parts PPs 




CC-INFO 

< 




« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup ack' > 

» 






CC-INFO 




« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

» 



Figure C.13: Outgoing parallel calls: line pre-selection by PP, Manual dialling of called number 



C.4.1 .4 FP-managed line selection - IVIanual dialling of called number 

Use case: The PP initiates a parallel call with 'ICIS'H / '17'H (e.g. the user pressed the R/INT key before manually 
dialling the called number). The FP replies with the call-id as soon as it received the first message (however preceded 
by the 'CS call hold' call status for the first call), and before dialling of the called number. When sending the call-id, the 
FP cannot send the hne-id together with it (because FP does not know at this stage if PP will use FP-managed line 
selection). 

NOTE: This use case is listed here as a reminder, as it is already presented as a mainstream use case in the 
"Outgoing parallel call initiation" procedure (see clause 7.4.3.5.1, figure 5). 
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C.4.1 .5 Unsupported new outgoing parallel call 

Use case: The PP initiated an outgoing parallel call (external or internal) at a point in time where the FP and/or the Une 
cannot support the additional call. A "busy system or line notification" (see clause 7.4.8.3) is sent to the PP. If a call id 
was assigned to the new call (a call context was created on FP side and the call id was notified to the PP), a "call 
release" should also be sent. 




FP 



Ongoing call (external or internal) , call id = 1 



Outgoing call initiation including line selection by the PP (not FP-managed) 

CC-INFO 



Une selected for the call (if 
external) by an NG-DECT Part 3 
PPusing the CALL-INFO 
method 



Line selected for the call (if 
external) by a GAP, an NG- 
DECT Part 1 , or (possibly) an 
NG-DECT Part 3 PP using the 
I KEYPAD method 



« MULTI-KEYPAD, < Keypad info = '1C1 57 '17'H -i- 'called number' > » 

« CALL-INFORMATION, 
< id type = 'Line identifier', subtype = 'external call', value = 'u' > » 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1 C1 5' / '1 7'H -i- '23 3u'H -i- 'called number' > 
» 



* Busy system : assign call id anyway (if 
not already done) and release the call 

4 



Line identifier is only sent to 
NG-DECT Part 3 PPs 



Call id assignment 

CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call proc' > 

» 



ii 



Busy system and call release 

CC-INFO 



If required by the Tones provision' feature « SIGNAL value = 'busy tone' = '04'H » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call disconnecting' > 

< id type = 'Call status', subtype = 'Call status reason' value = 'system busy' > 



CC-INFO 



After some time out 



^ 

« CALL-INFORMATION, 


< id type/subtype = 


'Call identifier', value = '02'H > 


< id type/subtype = 


'Call status', value = 'CS idle' > 


» 






Return to previous call 


^ 


CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype - 'Call status'; value = 'CS call connect' > 



Figure C.I 4: Outgoing parallel calls: unsupported new outgoing parallel call 
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C.4.2 Incoming parallel calls 

C.4.2.1 Two simultaneous incoming calls on two different lines 

Use case: the PP is attached to several lines. An incoming call is received on two different lines. This use case shows 
that from the PP point of view, this use case does not fundamentally differ from the use case where two simultaneous 
calls occur on a single line. 



PP 

attached at least to 
two lines u and v 



FP 



Network 



CC-SETUP 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number 1' > » 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > » 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< id type/subtype = 'Call identifier' value = 'call-id 1'> 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number 2' > » 




Incoming call to line u 
from 'calling number 1' 




Incoming call to line v 
from 'calling number 2' 



If required by tfie Tones 
provision' feature 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = v > » 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< id type/subtype = 'Call identifier' value = 'call-Id 2' > 

< id type/subtype = 'Call status', value = 'CS call setup' > 



Figure C.I 5: Incoming parallel calls: two simultaneous incoming calls on two different lines 
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C.4.2.2 FP release of waiting call when remote party hangs up 

Use case: use of call release from the FP when the remote partie hangs up, occurring even before the PP answered the 
call; in that case there is no need for a 'CS call connect' call status for the first call which was not disconnected (waiting 
call not answered). 



PP2 

attached to line u 



FP 



Network 




CW tone 
beared by user 



Line on which waiting call 
occurred if external 



CW context 
created 



CW context 
deleted 



Call established with call Id 1 (external or internal) 



CC-INFO 




« SIGNAL value = 'call waiting tone' = '07'H » If required by the Tones 

provision' feature 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype = line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier, 

value = 'waiting call id' = call id 2 > 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 



Call release of the (non answered) waiting call 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'call id 2' > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 




Call established with call Id 1 continues 



remote party 
hangs up 




Figure C.I 6: Incoming parallel calls: FP release of waiting call when remote party hangs up 

NOTE: There is no need here for a 'CS call connect' for the first call because the call waiting was not yet 
accepted). 

C.4.2.3 Two incoming calls before user answers 

Use case: Two calls are arriving before the user answers any of them. Both calls are presented to the user on the MMl 
and the user selects one of them. 

For this revision of the present document, the FP blocks the second incoming call presentation until the first call 
presentation is terminated (i.e. until this first call is accepted or released). 



NOTE: Other more advanced behaviours are left for further study. 
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PP1 

attached to lines u and v 
(v may be equal to u) 



FP 



Network 



Line on which waiting call 
occurred if external 



If call with call-id 1 is 
accepted bv the user 



CC-SETUP 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', valije = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'waiting call id' = cal id 1 > 

< id type/subtype = 'Call status', value = 'CS call setup'> 

» 

CC-ALERTING 



First incoming 
call (call id 1) 



CC-CONNECT 



CC-CONNECT-ACK 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 
value = 'waiting call id' = call id 1 > 

< id type/subtype = 'Call status', value = 'OS call connect'> 



CW tone 
beared by user 



Line on which waiting call 
occurred if external 



Call waiting indication (call-id 2) is deferred until first call 
presentation is terminated (call accepted or released) 

CC-INFO 




Incoming call 
arrives on FP side 



« SIGNAL value = 'call waiting tone' = '07'H » If required by the Tones 

provision' feature 
« CALLING PARTY NUMBER, ^ 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'v' > 

< id type = 'Line identifier', subtype = 'line type information', val|je = 'xy'B > 

< id type/subtype = 'Call identifier', 
value = 'waiting call id' = call id 2 > 

< id type/subtype = 'Call status', value = 'CS call setup'> 



Figure C.I 7: Incoming parallel calls: Two incoming calls before user answers 



C.4.3 Call waiting represented as first call when user hangs up 

Use case: the PP is attached to a multi-call line. A call is on going from PPl. A second incoming call is presented to the 
line. The PP hangs up and the call is represented as a first incoming call. 
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PP 

attached to 
multiple-call line u 



FP 



Network 



Call waiting 
indication 



User 
hangs up 

Incoming call 
presentation 




Call established with call Id 1 (externa 



CC-INFO 



or internal) 





Incoming call from 
'calling number' 



« SIGNAL value = 'call waiting tone' = '07'H » If required by the Tones 

provision' feature 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type = 'Line identifier', subtype = line type information 
<id type/subtype = 'Call identifier' value = 'call Id 2' > 
<id type/subtype = 'Call status' value = 'CS call setup' > 

CC-RELEASE 



CC-RELEASE-COM 



CC-SETUP 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value t 'u' > 

< id type = 'Line identifier', subtype = line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier' value = 'call id 2' > 
<id type/subtype = 'Call status' value = 'CS call setup' > 
» 

NOTE: The «CALL-INFORMATION» information element is not sent in a CC-RELEASE or CC-RELEASE-COM 

message. 

Figure C.I 8: Call waiting represented as first call when user hangs up 



= u > 

value = 'xy'B > 



C.5 List access service use case examples 



C.5.1 General 



In the following clauses, several use case examples for list access are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows are always 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperabiUty. 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that must convey it. Please note that they should not be onaitted when implementing 
equivalent cases. 
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j.2 Use case: transfer number from missed call list to contact 
list 



PT 



FT 



user starts missed call list 



CC-Setup 



IE « BASIC_SERVICE < Call Class=LiA service call setup > » 

CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session , missed call list, Nb sorting field 
identifiers=0 » 



IWU-lnfo 



IE « IWU to iWU= start session confirm, session identifier=1 , Total number. 
Sorting field identifier 1=date and time » 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part i » 



user selects entry to save in contact list 



IWU-lnfo 



IE « IWU to IWU= start session, contact list, Nb sorting field identifiers=0 » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier=2, Total number. Sorting 
field identifier1=name, Sortina field identifier2=First name » 



Figure C.I 9: List access use case: transfer number from missed call list to contact list (1/2) 
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PT 



FT 



IWU-lnfo 



IE « IWU to IWU= save entry, session id=2, entry identifier=OOH » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id=2, content part 1 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id=2, content part j » 



IWU-lnfo 



IE « IWU to IWU= save entry confirm, session id=2, position index, entry 

identifier =xxH » 



IWU-lnfo 



IE « IWU to IWU= end session, session ldentifler=1 » 
IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier=1 » 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier=2 » 
IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier=2 » 



CC-RELEASE 



CC-RELEASE-COM 



Figure C.20: List access use case: transfer number from missed call list to contact list (2/2) 

The second session might also be established after release of the first session. FP shall be capable to handle at least two 
sessions independently. 
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C.5.3 Use case: select and call internal party 



PT 



FT 



Direct PT initiated link establisiiment 



CC-Setup 



IE « BASIC_SERVICE <Call Class= LiA service call setup> » 

CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session, internal names list, Sorting field 

identifierl =number » 

IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier, Total number. 
Sorting field identifierl =number » 

IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 

IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-lnfo 



IE « MULTI-KEYPAD, int-key + number digits » 



Figure C.21 : List access use case: select and call internal party 

The int-key is necessary at least in case basic service is not internal call. 
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C.5.4 Use case: select and call number from contact list 



PTs 



FT 



Direct PT initiated link establisiiment 



CC-Setup 



IE « BASIC_SERVICE < Call Class= LiA service call setup > » 

CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session, contact list, Nb sorting field identifier=0 » 



IWU-lnfo 



E « IWU to IWU= start session confirm, session identifier. Total number. Sorting 
field identifierl =name Sorting field identifier2= first name » 

IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 

IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-lnfo 



IE « MULTI-KEYPAD, 1CH 15H + number digits » 



Figure C.22: List access use case: select and call number from contact list 
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C.5.5 Use case: save entry with invalid format 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= save entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 (invalid entry format) » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m (invalid entry 

format) » 



IWU-lnfo 



IE « IWU to IWU= negative acknowledgement, session id, reject reason=entry 

format incorrect » 



Figure C.23: List access use case: save entry with invalid format 



C.5.6 Use case: read invalid start index 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= negative acknowledgement, session id, reject 
reason=invalid start index » 



Figure C.24: List access use case: read invalid start index 
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C.5.7 Use case: modify a PP internal name 

The user edits the internal name of the PP number '3' in the DECT system. This use case can be used just after 
subscription registration or later. 



PP FP 











Internal names list access start session 






IWIl-INFO 

1 V V W 1 1 >l 1 \w/ 




> 

IE « IWU to IWU=search entries, session Id, matching optlon=OOH, 
searched value = 33H, counter=1 , list of field identi fiers= Number id. Name id » 

11 A f 1 1 IK 1^/^ 

IWU-INFO 


< 

IE « IWU to IWU=search entries confirm, session id, start Index, counter=1 » 

IWU-INFO 


< 

IE « IWU to IWU=data pacicet last, session Id, content part=(entry 
Identifier, number, name) for 3"^ entry » 

IWU-INFO 


> 

IE « IWU to IWU=edit entry, session Id, entry identifier, list of field 
identlflers= number Id, name id » 

IWU-INFO 


-< 

IE « IWU to IWU=edit entry confirm, session Id, start index » 

IWU-INFO 


IE « WU to IWU=data packet last, session id, content part= ontent part= 
(entry identifier, number, name) for 3'''' entry » 




user updates the 'name' field for 3"* entry in internal name list 






IWI l-INFO 

► 




IE « IWU to IWU=save entry, session Id, entry identifier » 
IWU-INFO 


s ► 

IE « IWU to IWU=data packet last, session id, content part = 3 

entry content updated » 
iWU-iNFO 


< 

IE « iWU to IWU=save entry confirm, session id, entry identifier, start index » 




Internal names list access end session 












FP notifies PP 3 of the changing of its name using clause 7.4.10.2 











Figure C.25: List access use case: modify a PP internal name 
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C.5.8 Use case: entry distributed over two data packets 

Read the missed call list, the number of requested entries is 1 with aU possible fields. The first entry in the Ust is the 
following: 

• CLIP= "0674011776" 

• CNIP = "J.Rene BIDA" 

• 8 calls received 

• Last call received on 17/03/09 at 12h07mn08s 

The data content of this entry exceeds the 56 octets limit, so the entry is sent over two data packets: one "data packet" 
command followed by one "data packet last" command. Each data packet is sent in a separate IWU-INFO «IWU to 
IWU» message as defined in tables C.6 and C.7. 



Table C.6: Example of one entry sent over two 'Data packet' commands - 1^* «IWU to IWU» 



Infornnatioti element 


Field within the Information 

aI Ann Ant 


Standard values 
wiinin ine Tieiu/ic 


Normative action/comment 


^^l\A/l 1 trt l\A/l 
«IVVU 10 IVvU» 


<LGngth of contGnt> 


odM 


1 — — 7 

Length of content 




<Protocol Discnrninator> 


Don 


List access 




<Command> 


\ on 


Data packet 




<SGSsion iclentifier> 


1-1 

o \ n 


Session identifier (session id=1) 




<tMTry loeniiTier Tor i enTry> 


Qi U 

oi n 


iQeriTiTier ot ine GnTry (GnTry =ui nj 




<Entry lGngth> 


bOn 


LGngin (iGngTn=oL'Mj 




<Entry fiold idGntiflGr 1 > 


\j \ n 


Fiold IdontifiGr = NumbGr 




<tniry Tieiu iengin> 




Lengin (iengin=UDnj 




<tniry Tieiu conieni u> 




rroperiy (euiiaDie=u, own=u, ini=u; 






oUn 


Digit (1 ) = 






oon 


Uigit = b 






o/n 


Digit \6) = 1 






34H 


Digit (4) = '4' 






30H 


Digit (5) = '0' 






31 H 


Digit (6) = '1' 






31 H 


Digit (7) = '1' 






37H 


Digit (8) = 7 






37H 


Digit (9) = 7 




<Entry field content j> 


36H 


Digit (10) = '6' 




<Entry field identifier 2 > 


02H 


Field identifier = Name 




<Entry field length> 


SDH 


Length (length=ODH) 




<Entry field content 0> 


80H 


Property (editable=0) 






4AH 


Character (1) = 'J' 






2AH 


Character (2) = '.' 






52H 


Character (3) = 'R' 






62 H 


Character (4) = 'e' 






6EH 


Character (5) = 'n' 






C3H 


Character (6) = 'A' 






A9H 


Character (7) = '©' => 'e' 






20H 


Character (8) = " 






42H 


Character (9) = 'B' 






49H 


Character (10) = T 






44H 


Character (11) = 'D' 




<Entry field content k> 


41 H 


Character (12) = 'A' 




<Entry field identifier 3 > 


03H 


Field identifier = Date and Time 




<Entry field length> 


88H 


Length (length=08H) 




<Entry field content 0> 


80H 


Property (editable=0) 






COH 


Coding= Time and Date 
Interpretation = The current 
time/date 






09H 


Year = 2009 






03H 


Month = March 






17H 


Day = 17 
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12H 


Hour = 12 






07H 


Kyiini itp — 7 

1 VI 1 1 1 LJ — / 






08H 


QpprjnH — R 




<:'Fntr\/ fiplH mntpnt 1"^ 

^1 1 ILI y II^IU OUI 1 Ld IL 


OOH 


Timp 7nnp — 4-0 
1 II 1 ic ic — 




^-Fntrv fiplH iripntifipr A 

^1 1 ILI y lldl_l lUOl ILIM^I t ^ 


04H 


Fiplfi iripntifipr — Npw 

1 I^IU lUwIlllllwl — I^I^VV 




•tf'Fntrv fiplH Ipnnth"^ 

^1 iiLiy 1 i^iu idi^Lii'^ 


81 H 


1 pnnth Mpnnth— 1^ 




*^"Fntr\/ fipiri fnntpnt 

1 1 1 Li y 1 i^ivj 1 1 Id 11 \j ^ 


AOH 


Prnnprtv ^prlit^hlp— fl npw— 1^ 




<:'Fntr\/ fipIri iHpntifipr ^ 


05H 


FiplH iripntifipr — 1 inp n;^mp 

1 IdU lU^IILIII^I — 1 111^ lldlllC 




^Fntrv fiplrl lpnntlT:> 

^1 IILiy II^ILJ I^IIULII>^ 


87H 


1 pnnth 
ly Li 1 




^Fntrv fiplrl rnntpnt n":> 
VI — 1 ILI y iidu lid 11 


80H 


Prnnprtv ^pHltphlp— 






56H 


Charartpr Ml - 'V 






6FH 


Wl icli ClVjlCI \^) — 






49H 


nhoraptpr {"W - T 
wiiaidUld — 1 






50H 


Character (4) = 'P' 






20H 


Character (5) = " 




<Entry field content nn> 


31 H 


Character (6) = '1' 




<Entry field identifier 6 > 


06H 


Field identifier = Line id 




<Entry field length> 


82H 


Length 




<Entry field content 0> 


80H 


Property (editable=0) 


Table C.7: Example of one entry sent over two 'Data packet' commands - 2"'' «IWU to IWU» 


Information element 


Field within the information 


Standard values 


Normative action/comment 




element 


within the field/IE 




«IWU to IWU» 


<Length of content> 


08H 


Length of content 




<Protocol Discriminator> 


03H 


List access 




<Command> 


14H 


Data packet last 




<Session identifier> 


81 H 


Session identifier (session id=1) 




<Entry field content n> 


81 H 


Identifier value = 01 H 




<Entry field identifier 7 > 


07H 


Field identifier = Number of calls 




<Entry field length> 


82H 


Length 




<Entry field content 0> 


80H 


Property (editable=0) 




<Entry field content p> 


08H 


value = 8 calls 



C.6 List access service witli voice calls (additional use 
cases and procedure diagrams) 

C.6.1 General 

In the following clauses, several procedure diagrams for list access service combined with voice calls are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows are always 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperabiUty. 

C.6. 2 List access when a voice call is already ongoing 

Please note that for clarity of the flowcharts, the line identifier is not mentioned. However it has to be implemented and 
managed correctly as defined by the present document. 

C.6. 2.1 Use case: Consult a list during a voice call 

Use case: Look for the number of a contact while you are in voice call and then come back to the voice call. 
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PP FP 





Ongoing call 1 (external or internal) with call-id 1 
Put call 1 on hold (mandatory only If Cf channel used for list access, optional otherwise) 




r 


CC-INFO 


■ 


> 

« MULTI-KEYPAD, info = '1C 41'H » 

« CALL-INFORMATION, Line Id, 'call-Id 1" > 




Access contact list (within call 1) 






IWU-INFO 




« IWU-TO-IWU <Commancl = start session>, <List identifier = contact list> » 

IWU-INFO 


4 

<< IWU-TO-IWU <Command - end session confirm>. <session identifier> » 




Resume call 1 (mandatory only if Cf channel used for list access, optional otherwise) 




r 


CC-INFO 




1 

« MULTI-KEYPAD, info = 1C 42 H » 

« CALL-INFORMATION, Line Id, 'call-Id 1' > 


• 




•s^Z^^I^^ Back to ongoing call 1 (external or internal) ^^]^^|^;> 
Figure C.26: List access use case: consult a list during a voice call 





C.6.2.2 Use case: call transfer using internal names list (first call explicitly 
put on hold) 

Use case: Ongoing call is put on hold before establishing a parallel internal call using the internal names list. The first 
call is then transferred. It shows in particular that a call can optional be put on hold before an outgoing second call is 
made. In this case, it is proposed that an additional call id is attached to the list access. 

NOTE: The list access re-uses call idl . 
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PP FP 





<CII^^]]^^^^^^ ' Ongoing call 1 (external or internal) with call-id 1 ^^^^^]];;;;;>> 

Put call 1 on hold 




1 


CC-INFO 


■ 


1 

« MULTI-KEYPAD, info = '1 C 41 'H » 

« CALL-INFORIVIATION, Line Id, 'call-Id 1' > 

CC-INFO 


< 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id 1 > 
id type/subtype = 'call status', value='CS call hold' > » 




Access Internal names list to find call transfer target (within call 1) 






l\A/l 1 IMCO 
IVVU-INrU 




► 

« IWU-TO-IWU <Command = start session>, <List identifier = internal names list> » 

IWU-INFO 


4 

« IWU-TO-IWU <Command = end session confirin>, <session identifier> » 




Establish parallel internal call 2 






CC-INFO 

^ 




« MULTI-KEYPAD, 17H + terminal id number » 
^ CC-INFO Call id assignment by the FP 


« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = 'call id 2' > 
id type/subtype = 'call status', value='CS call proc'> » 




Call transfer request 






CC-INFO 




► 

« MULTI-KEYPAD, info = '1C 34'H » 
Only if the PP « CALL-INFORMATION, 
implements ^ Identifier type = 'Call identifier' > 
the "Call ^ Identifier subtype = 'Call identifier' > 
identification" feature < Identifier value = 'call-id 1 ' > 

» 



Figure C.27: List access use case: call transfer using internal names list 
(first call explicitly put on hold) 



C.6.2.3 Use case: call transfer using internal names list (first call implicitly 
put on hold by internal call) 

Use case: Ongoing call is implicitly put on hold before establishing a parallel internal call using the internal names list. 
The first call is then transferred. It shows in particular that the '17'H impUcitly puts the ongoing call on hold. 

NOTE: The list access re-uses call id2. 
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PP FP 





■<^[|[^^^^^ Ongoing call (external or internal) with call-id 1 

Request internal call, call 1 implicitely put on hold 






CC-INFO 

► 




« MULTI-KEYPAD, 17H » 
« CALL-INFORMATION, Line Id, 'call-id 1" » 

CC-INFO 


A 

<r<r CAI 1 -INFORMATION < id tvnp/qiihtvnp - 'nail iripntiflpr' valup - call id 1 > 

id type/subtype = 'call status', value='CS call hold' > » 
CC-INFO 


A 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id 2 > 
id type/subtype = 'call status', value='CS call setup ack'> » 




Access internal names list to find call transfer target (within call id 2) 






IWU-INFO 




► 

« IWU-TO-IWU <Command = start session>, <List identifier = internal names list> » 

■ ■ ■ 

IWU-INFO 

« IWU-TO-IWU <Command = end session confirin>, <session identifier> » 
•4 






csiaDiisn paraiiGi iniGrnai can ^ 






CC-INFO 




► 

« MULTI-KEYPAD, Called nb = terminal id number » (call-id=2) 

CC-INFO 


< 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id 2 > 
id type/subtype = 'call status', value='CS call proc'> » 




Call transfer request 






CC-INFO 

« MULTI-KEYPAD, info = '1C 34'H » 
Only if the PP CALL-INFORMATION, 
implements ^ Identifier type = 'Call identifier' > 
the "Call Identifier subtype = 'Call identifier' > 
identification" feature < Identifier value = ■call-id 1 ' > 
» 






Figure C.28: List access use case: call transfer using internal names list 
(first call explicitly put on hold) 
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C.6.2.4 Use case: establishing a parallel call using contact list 

Use case: During an ongoing call, the user establishes a parallel external call using the contact list. In this case, there is 
no need for an additional call id for the Ust access: it is done within existing call. 



p 


» FF 

<C;||]^]^^^ ' Ongoing call (external or internal) on call id1 

Put call 1 on hold 






CC-INFO 


---1 
1 


■ 


► 

« MULTI-KEYPAD, info = '1 C 41 'H » 

« CALL-INFORMATION, Line Id, 'call-id 1' » 
CC-INFO 


1 

« CALL-INFORMATION, Line Id, 'call-id 1' , call status = 'CS call liold' » 




Access contact list to find a contact (within call id 1) 






IWU-INFO 




: : — : — 7. : ^ 

« ivvu- 1 ^j-ivvu <uornmana = sian session>, <lisl lueniiTier =conTacT mst> » 

l\A/l 1 IMC/^ 

IWU-INrU 

« IWU-TO-IWU <Gommand = end session confirm>, <session identifier> » 


^ 




Try to establish parallel external call 2 

CC-INFO 




► 

« MULTI-KEYPAD, '1C15'H + external number » (call-id 1) 

CC-INFO 


^ « CALL-INFORMATION, Line Id, 'call id 2, call status='CS call proc'> » 
-^^^^^^^^^^^^^^^ ^ Parallel external call establish on call id2 



Figure C.29: List access use case: establisliing a parallel call using contact list 



C.7 DECT system settings diagrams 
C.7.1 General 

In the following flowcharts, we assume that: 

• N lines are defined, i.e. 'Total number of entries' = N in hne settings list before starting hnes settings session. 
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• The total number of registered PPs is M, i.e. 'Total number of entries' = M in internal names list before starting 

internal names session. 

• Only one data packet command is necessary to read one entry content, i.e. 'data packet last' command is 
received directly. 

• The fields are not PIN protected (except when stated other wise). 

NOTE: In the following flowcharts, the read entries or search entries might be done prior to the sequence (in a 
previous session for example). But this is not the most usual behaviour as the PP may probably show the 
current value of the setting before enabling the user to modify it. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that convey it. Please note that it should not be omitted when implementing equivalent cases. For example the 
call identifier is assigned by the FP after {CC-SETUP} message. 

In the following use cases, it is assumed that "Early encryption" feature [GAP. M. 15] is not implemented. In the 
flowcharts, the encryption is started by the FP systematically after the list access call setup. However, some 
implementation flexibility is allowed concerning the point in time when link is encrypted as long as: 

• PIN code exchange is done over an encrypted link (see clause 7.4. 1 1 . 1). 

• List access service call gets finally encrypted at some point in time. See [GAP.N.35] feature, encryption of all 
calls procedure (see clause 8.45.1 of [12]). 



C.7 



2 Modifying tine PIN code 



Use case: FP without keyboard, the user modifies the system PIN code from the PP. 
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PP 



FP 



CC-SETUP 



« BASIC SERVICE <Call Class=LiA service call setUD> » 
CIPHER-REQUEST 



Encrypted 



CC-CALL-PROC 



IWU-INFO 



IE 



«IWU to IWU= start session, DECT system settings list, Number of sorting fields 



IWU-INFO 



:0» 



IE «IWU to IWU= start session confirm, session identifier. Total number=1 > 



Read Current 



'IN code: 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , countered H, 
list of field identifiers= Current PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1 » 

IWU-INFO 



IE «IWU to IWU= data pacl<et, session id, content part » 
(FFH FFH FFH FFH) 

IWU-INFO 



IE «IWU to IWU= data paclcet last, session id, content part » 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Current PIN code » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



IE «IWU to IWU= data paclcet last, session id, content part= (entry identifier. 
Current PIN code) > (FFH FFH FFH FFH) 



Save Current *iN code 



User enters current PIN code 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data paclcet last, session id, content part = current PIN code>: • 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 



FP checks if PIN code entered by the user matches current system PIN 



Figure C.30: Modifying tlie PIN code (1/2) 
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PP 



FP 



r 



Encrypted 



entered PIN 



;ode matches current system PIN 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= New PIN code, FP version » 

IWU-INFO 



IE V...IWU lo IWU= read entries^nfirm, sessiiun lo. sitirl .ndex. u>iJt:!er=l 

MMIIIIIIIIIIIIIIIPI llil 



IE «IWU to IWU= data packet, session id, content part » 
(FFH FFH FFH FFH) 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part : 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= New PIN code » 



IF .:<IWU to IWU- edit entry confirm, session Id, st f ' 

■^^^^ IWU-INFO ^ B^^^^ 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier. 
New PIN code (FFH FFH FFH FFH) > 



New PIN code is entered twice. If equal, PP saves the new PIN code value 



IWU-INFO 



IE «IWU to IWU= save entry, session id. entry identifier» 



IF I /U In IWU- data packet last ' i '.id runlenl pnrl Nuw PIN (.n !' 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start jndex» 



DECT system settings end session 



Figure C.31 : lUlodifying the PIN code (2/2) 



C.7.3 Resetting the base 



Use case: Reset all DECT system and line settings to their default value. 
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PP 



FP 

J 



DECT system settings start session (on encrypted linl<) 



Read DECT 



iystem settings: 



IWU-INFO 



IE «IWLI to IWL)= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= Current PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data paclcet, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data paclcet iast, session id, content part » 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Base reset » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



IE «IWU to IWU= data paclcet last, session id, content part= (entry identifier. 

Base reset) > 



User confirms system and line settings reset 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (Base reset, YES) >|> 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session Id, entry identifier, position 

index, total number of available entries » 



DECT system settings end session 



Figure C.32: Reseting the base 



C.7.4 Resetting the base (PIN code protected field) 



Use case: the use case is the same as the previous one except that the 'Base reset' field is PIN code protected. 



ETSI 



294 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



PP 



FP 
I 



DECT system settings start session (on encrypted linl<) 



Read DECT 



system settings: 



IWU-INFO 



IE «IWL) to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= Current PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data paclcet, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data paclcet last, session id, content part » 



PIN code ch icking: might be done at any time during the LIA service call (here or before) 



Edit and save the current PIN code 



FP checks if PIN code entered by the user matches current system PIN 



If entered PlH code matches current system PIN 

IWU-INFO 





IE «IWU to IWU= edit entry, session id, entry identifier. 


► 




list of field identifiers= Base reset » 






IWU-INFO 




^ — 


IE «IWU to IWU= edit entry confirm, session id, start index » 




< — 


IWU-INFO 





IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 

IIIIIIIIIIIW 



User cot't.rnis svsten- and I ne eetlngs reset 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (Base reset, YES) >f> 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id. entrv identifier, oosition 
i.-idex. lo:al number of available entnes 



DECT system settings end session 



Figure C.33: Reseting the base (PIN protected field) 
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C.8 Line settings diagrams 
C.8.1 General 

In the following flowcharts, we assume that: 

• N lines are defined, i.e. 'Total number of entries' = N in the line settings list before starting lines settings 
session. 

• Only one data packet command is necessary to read one entry content, i.e. 'data packet last' command received 
directly. 

In the following flowcharts, the read entries or search entries might be done prior to the sequence (in a previous session 
for example). But this is not the most usual behaviour as the PP may probably show the current value of the setting 
before enabling the user to modify it. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that convey it. Please note that it should not be omitted when implementing equivalent cases. For example the 
call identifier is assigned by the FP after {CC-SETUP} message. 

In the following use cases, it is assumed the link encryption is started by the FP at list access call setup although not 
always depicted in the flowcharts. As explained in clause C.7.1, some flexibility is allowed concerning this 
implementation choice. 

C.8. 2 Changing the settings of a line 

Use case 1: The user edit the line settings of the line number 'i'. Read only the selected entry. 
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PP 



FP 



CC-SETUP 



« BASIC_SERVICE <Call Class=LiA service call setup> » 
CC-CALL-PROC 



IWU-INFO 



IE «IWU to IWU= start session, lines settings, Number of sorting fields =0 » 

IWU-INFO 

«IWU to IWU= start session confirm, session identifier, total number=N » 



Line i selectee by the user (\e 1.. N): 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1, counter=01 H, 
list of field identifiers= Line id id. Line name id, Multiple calls mode id » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data pacl<et last, session id, content part for i entry» 

IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers^ Line id id, Line name id, Multiple calls mode id» 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE 



«IWU to IWU= data packet last, session id, content part= content part for i" entry: 



User updates the settings for i line in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= i entry updated : 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position index, 
total number of available entries » 

IWU-INFO 



IE «IWU to IWU= end session, session identifier» 
IWU-INFO 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List change indication, Line settings, 
N> > « CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COM 



FP notifies all 
PP attached 
to the line 



Figure C.34: Changing tlie settings of a line (use case 1) 

Use case 2: The user edit the line settings of the line number 'i'. Read all N entries before editing the selected entry. 
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PP FP 





CC-SETUP ^ 




« BASIC_SERVICE <Call Class=LiA Service call setup> » 
^ CC-CALL-PROC 


IWU-INFO 


w 

IE «IWU to IWU= start session, lines settings, Number of sorting fields =0 » 

IWU-INFO 


^E «IWU to IWU= start session confirm, session identifier, total nunnber=N » 

IWU-INFO 

^ 


IE «IWU to IWU= read entries, session id, start index =1, counter=N, 

MST OT TI6I0 l06nilTI6rS= Line 10 10, LlnG ricime 10, MUlTipic Calls m006 10 » 

IWU-INFO 


A 

IE «IWU to IWU= read entries confirm, session id, start index, counter=N» 

IWU-INFO 


< 

IE «IWU to IWU= data paclcet, session id, content part » 

IWU-INFO 

4 


IE «IWU to IWU= data pacl<et last, session id, content part » 


Line i selectee 

IE 


by the user (lei.. N): IWU-INFO 


>> 


► 

IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Line id id, Line name id, Multiple calls mode id» 

IWU-INFO 


A 

IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 


«IWU to IWU= data pacl<et last, session id, content part= content part for i" entry 



User updates the settings for i line in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= i entry updated » 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position index 
total number of available entries » 
IWU-INFO 



IE «IWU to IWU= end session, session identifier» 
IWU-INFO 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List cfiange indication, Line settings, N> > 

« CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COM 



FP notifies 
all PP 

attached to 
the line 



Figure C.35: Changing the settings of a line (use case 2) 
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C.8.3 Changing the name of a line 

Use case: The user edit directly the hne name of the Une number '3'. 



PP 



FP 



CC-SETUP 



«Basic Service=< Call Class = LiA Service call setuD > » 
CC-CALL-PROC 



IWU-INFO 



IE «IWU to IWU= start session, lines settings list, Number of sorting fields =0» 

IWU-INFO 



IE «IWU to IWU= start session confirm, session identifier, Total number=N 

IWL^iKlFO 



IE «IWU to IWU= search entries, session id, matching options= OOH, 
search string = '33'H, counter=1 , list of field identifiers= Line Id id. Line name id » 

IWU-INFO 



IE «IWU to IWU= searcli entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data paclcet iast, session id, content part= (entry identifier, 
line Id, Line name) for 'line 3' » 

IWU-INFO 



IE «IWU to IWU= edit entry, session Id, entry identifier, list of field jdentifiers= 
Line Id id. Line name id » 
IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (entry Identifier, 
line Id, Line name) for 'line 3' » 



User updates the 'Line name' field for 'line 3' entry in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session Id, entry ldentlfler» 
IWU-INFO 



E «IWU to IWU= data paclcet iast, session id, content part = 'line 3' content updatpd 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position 
index, total number of available entries » 

IWU-INFO 



IE «IWU to IWU= end session, session identifier» 
IWU-INFO 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List change indication. Line settings, 
N> > « CALL-INFORMATION, Lineld » 

CC-RELEASE 



FP notifies all PP 
attached to the 
line 



CC-RELEASE-COM 



Figure C.36: Changing the name of a line 
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C.8.4 Changing the name of a line (PIN protected field) 

Use case: the use case is the same as the previous one except that the 'linename' field is PIN code protected. 



ETSI 



300 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



PP 



FP 



Line settings start session (on encrypted linl<) 



Read Lin 



'3' settings: 



IWU-INFO 



IE «IWU to IWU= search entries, session id, matctiing options= OOH, 
searcli string = '33'H, counter=1 , list of field identifiers= Line Id id, Line name id » 

IWU-INFO 



IE «IWU to IWU= search entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data pacl<et last, session id, content part= (entry identifier, 

line Id, Line name) for 'line 3' » 



PIN code 



checking might be done at any time dunng the LiA service call (here or befor^) 



Start a DECT system settings list session 



Edit and save tfie current PIN code 



FP checks if PIN code entered by the user matches current system PIN 



Close the DECT system settings list session (optional) 



If entereq PIN code matches current system PIN 

IWU-INFCb 



IF oclWU *o IWU- edit entry, session id. entry idertifier. lis* of field Identifi^rs- 

IIIIIIIIIIIIIIIIIB^^^^ 



IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (entry identifier, 
line Id. I ine name) for 'line 3' » 



user updates the 'Line name' field for 'line 3' entry in line settings list 



IWU-INFO 

IF «IWU lo IWU- save entry session id, entry identlfier» 



IE 



;IWU to IWU= data packet last, session id. content part = line 3' content updat< 

iwLNINFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position 
index, total number of available entn°= » 



Line settings end session 



FACILITY 



«EVENTS NOTIFICATIONS, <List change indication, Line settings, N> > 

« CALL INFORMATION, Lineld » 



FP notifies all PP 
attached to the 
line 



Figure C.37: Changing the name of a line (PIN protected field) 
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C.9 Use cases for 'Off-hook CLIP enabled DCIBS' lines 

This annex studies complex use cases for the 'Handling of hnes where second calls are signalled in-band' feature (see 
clause 7.4.3.10). 

C.9.1 Remote party hangup 'double call with in-band signalling' 
line 

This clause illustrates some of the issues possibly occurring on Off-hook CLIP enabled DCIBS lines when a remote 
party hangs up, but the FP is not aware of this event. See clause 7.4.3.10.3.1, subsection 'Remote party hang up in case 
of second call'. 

C.9.1 .1 Call waiting after 'remote party hangup' 

In this use case, the FP becomes aware of a remote party hangup when a new call waiting is indicated by the network. 
As a result, the FP releases one of the two existing calls by issuying a 'CS idle' call status with the corresponding call id 
(late release). Two subcases are covered: 

• late release (see note 1) of a former call waiting when a new call waiting occurs; 
NOTE 1: The 'late release' is defined in clause 3.1. 

NOTE 2: In the above subcase, the late release is not needed if the former call waiting has already been released 
following a timeout (never accepted waiting call). 

• late release of the call on-hold when a call waiting occurs. 

In both cases, the FP chooses to release the non-active call (former call waiting or call on-hold). In some case however, 
the FP might release the wrong call (i.e. if the remote party of the active call hanged up). In that case, the user may be 
faced with issue 2 described in the 'remote party hangup in case of second call' subsection of clause 7.4.10.3.1. 
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PP 



FP 



\ 



If required by the 'Tones 



context with call Id 2 
created on PP side 



Call context for call id 2 
still in alerting state 



External call 1 (with call id 1 ) currently in use by PP 



Call waiting indication 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, < Calling Party Address ■- 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', valu ! 

< id type='Line identifier', subtype='line type information', 

< id type = 'Call identifier', value = 'waiting call id' = '02'H 

< id type/subtype = 'Call status', value = 'CS call setup' 



Late release of former call waiting (call id 2) 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 



New call waiting indication 

CC-INFO 



External 
call waiting from 
'calling number' 



ailing number' > » 



= 'waiting call line Id' > 
/alue = '1y'B> 



1- CW remote party hang- 
up (not detected by the FP) 

2- Off-hook CLIP (Indicating 
new call waiting) 



3- FP guesses call 2 
remote hang up and 
performs a late 
release of that call 

(see note 1 & 2) 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, < Calling Party Address = 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type='Line identifier', subtype='line type information', 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call setup' ; 



;alling number' > » 

'waiting call line id' > 
\ia\ue = '1y'B> 



Figure C.38: Late release of former call waiting following new call waiting indication 



ETSI 



303 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



PP 



FP 



Two existing caii 
contexts on PP side 



If required by the 'Tones 



External call 1 (with call Id 1) currently In use by PP 
External call 2 (with call Id 2) on-hold 



Late release of call on-hold (call id 2) 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Gali identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS Idle' > 



Caii waiting indication 

CC-iNFO 



1- Remote party Inang-up 

(not detected by the FP) 

2- Off-hool< CUP (indicating 
new call waiting) 



3- FP guesses call 2 
remote hang up and 
performs a late 
release of that call 

(see note 1 ) 



« SIGNAL value = 'call waiting lone' = '07'H » 
« CALLING PARTY NUMBER, < Calling Party Address = 'clliing number' > » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type='Line identifier', subtype='iine type information', vfel 

< id type = 'Call identifier', value = 'waiting call id' = '03'H 

< id type/subtype = 'Call status', value = 'CS call setup' 



'waiting call line id' > 
lue = '1y'B> 



Figure C.39: Late release of call on-hold following call waiting indication 



C.9.1 .2 Outgoing parallel call after 'remote party hangup' 

In this use case, the FP becomes aware of a remote party hangup when the user initiates an outgoing parallel call. As a 
result, the FP releases one of the two existing calls by issuying a 'CS idle' call status with the corresponding call id (late 
release). Two subcases are covered: 

• late release (see note 1) of the call waiting when an outgoing parallel call occurs; 
NOTE 1: The 'late release' is defined in clause 3.1. 

NOTE 2: In the above subcase, the late release is not needed if the call waiting has already been released following 
a timeout (never accepted waiting call). 

• late release of the call on-hold when an outgoing parallel call occurs. 

In both cases, the FP chooses to release the non-active call (call waiting or call on-hold). In some case however, the FP 
might release the wrong call (i.e. if the remote party of the active call hanged up). In that case, the user may be faced 
with issue 2 described in the 'remote party hangup in case of second call' subsection of clause 7.4.10.3.1. 
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PP 



If required by the 'Tones 



context with call Id 2 
created on PP side 



Call context for call Id 2 
still in alerting state 



External call 1 (witfi call id 1 ) currently in use bv PP 



Call waiting indication 

CC-INFO 



FP 

SJ 

> 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, < Calling Party Address ■- 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', valut = 'waiting call line id' > 

< id type='Line identifier', subtype='line type information', /alue = '1y'B> 

< id type = 'Call identifier', value = 'waiting call id' = '02'H 

< id type/subtype = 'Call status', value = 'CS call setup' 

» 

1- One of the remote parties hangs up 

(not detected by the FP) 
I 

^ 2- outgoing parallel call Initiation received 



External 

call waiting from 
calling number' 



;alling number' > » 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1C15'H /'1 7' H > » 
CC-INFO call Id 1 put on-hold 



« CALL-INFORIVIATION, 

< id type/subtype = 'Call identifier', value = '01 'H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO release of call waiting (call Id 2) 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 



Call id assignement for the new outgoing second call 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call setup ack' 



3- FP guesses call 2 
remote hang up and 
performs a late 
release of that call 

(see notes 1 & 2) 



Figure C.40: Late release of call waiting following outgoing parallel call initiation 
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PP 



External call 1 (with call id 1) currently in use by PP 
\ ^ External call 2 (with call id 2) on-hold 



FP 

y 



CC-INFO 



1- One of the remote parties hangs up 

(not detected by the FP) 

I 

2- outgoing parallel call initiation received 



« MULTI-KEYPAD, < Keypad info = '1C15'H /'1 7' H > » 



CC-INFO call id 1 put on-hoid 
< 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 



CC-INFO Late release of call on-hold (call id 2) 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 



3- FP guesses call 2 
remote hang up and 
performs a late 
release of that call 

(see note 1 ) 



Call id assignement for the new outgoing second call 

CC-INFO 

A 

« CALL-INFORMATION, 

< id type/subtype = 'Call Identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call setup ack' ; 
» 



Figure C.41 : Late release of call on-hold after remote party hangup 
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Annex D (informative): 

Guidelines for implementation of DTMF 

D.1 Uplink DTMF transmission from FP to network 



Upon reception of the keypad information element from the PP. the FP has two options according to the network 
capabilities: 

• Digits are transmitted out of band using dedicated signalUng. 

• Digits are transmitted in band by inserting the corresponding audio encoded patterns in the audio bit stream in 

the active codec format. 

When connected to PSTN networks, the in-band generation method is used by the FP. 

If the FP is able to place calls on several lines from different networks that use different DTMF methods, the FP might 
have to adapt the uplink DTMF transmission on a line by line basis. This could be the case with the multiple lines 
feature. For example, one PSTN line uses the in-band method, and another VoIP line uses the out of band method. 



The current clause is valid for: 

• in-band DTMF generation from FP to PP; or 

• in-band DTMF generation from FP to network when in-band method is supported on network side. 
In-band DTMF shall be generated in the active codec format. 

The DTMF should respect ITU-T standards Q.23 [i.8] which defines pair of frequencies to be used and ITU-T 
Recommmendation Q.24 [i.9] which defines levels and durations. 

A recommended implementation for level and duration for the DTMF is the following: 

• Tone generation level: nominal - 10 dBmO per frequency 

• Tone generation time min: 80 ms 

• Inter DTMF generation time min: 80 ms 



D.2 



DTMF format 



ETSI 



307 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



Annex E (informative): 

Tones format in ITU-T recommendations 

The generated tones should be compUant with ITU-T Recommendations: E.180 (see [i.lO] and [i.l 1]) and E.182 
(see [i.l2]). 



Table E.I : Tones in ITU-T recommendations 



DECT Tones 


ITU-T Tones 


Ring-back tone 


Ringing tone 


Busy tone 


Busy tone 


Network congestion tone 


Congestion tone 


Call waiting tone 


Call waiting tone 


Intercept tone 


Intercept tone (note) 


Negative acknowledgment tone 


Negative indication tone (note) 


Dialing tone 


Dialing tone 


Off-liook warning tone 


Special information tone 



NOTE: These tones are not defined for all countries. Implementers should select one tone format among those 
available in ITU-T Recommendation E.182 [i.l2]. 
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Annex F (informative): 

Services and features defined in other specifications 

F.1 Services and features defined in TS 102 527-1 (New 
Generation DECT; part 1) 

The following informative annex shows the features and MAC/DLC services defined in TS 102 527-1 [21] (New 
Generation DECT; part 1), many of them are reused in the present document. This hst is informative, and shows the 
status in TS 102 527-1 [21] (Vl.2.1). In case of changes or divergences the original definitions at TS 102 527-1 [21] 
shall rule. 

F.I .1 New Generation DECT; part 1 , Speecli Services (clause 5.1 
of TS 102 527-1) 

Narrow band ADPCM G.726 voice service [NGl.l]: ITU-T Reconmiendation G.726 [15] narrow band codec 
[NGl.SC.l] over 32 kbit/s unprotected transmission channel. 

Narrow band PCM G.711 voice service [NG1.2]: ITU-T Recommendation G.711 [16] narrow band codec 
[NG1.SC.2] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz G.722 voice service [NG1.3]: ITU-T Recommendation G.722 [17] wideband codec [NG1.SC.3] 
over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz low rate G.729.1 voice service [NG1.4]: ITU-T Recommendation G.729.1 [18] wideband codec 
[NG1.SC.4] over 32 kbit/s improtected transmission channels. 

Super wideband 14 kHz MPEG-4 ER AAC-LD voice service [NG1.5]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.5] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 11 kHz low rate MPEG-4 ER AAC-LD voice service [NG1.6]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.6] over 32 kbit/s unprotected transmission channels. 

F.I .2 New Generation DECT; part 1 , Network (NWK) features 
(clause 5.2 of TS 102 527-1) 

Codec Negotiation [NGl.N.l): capability to negotiate the speech codec to be used in a communication, based on the 
supported capabilities in both peers and the previsions included in the present document. This feature may require slot 
type change. 

Codec Switching [NG1.N.2): capability to switch between different speech codecs during a call. This feature may 
require slot type change. 

F.I .3 New Generation DECT; part 1 , Data Link Control (DLC) 
services (clause 5.3 of TS 102 527-1) 

LUl Transparent Unprotected service (TRUP) Class 0/minimum_delay [NGl.D.l]: transparent unprotected 
service introducing minimum delay, transmission Class 0/min_delay as defined by EN 300 175-4 [4], clause 1 1.2. 

LUl Transparent Unprotected service (TRUP) Class [NG1.D.2]: transparent unprotected service introducing 

minimum delay, transmission Class as defined by EN 300 175-4 [4], clause 1 1.2. 

LU7 64 kbit/s protected bearer service [NG1.D.3]: protected service providing reliable 64 kbit/s transmission over 
packet type P80 incorporating EEC and ARQ protection mechanisms. Defined by EN 300 175-4 [4], clause 11.9. 



ETSI 



309 



ETSI TS 102 527-3 V1.2.1 (2010-04) 



LU12 UNProtected Framed service (UNF) Class [NG1.D4]: unprotected service introducing normal delay, 

transmission Class as defined by EN 300 175-4 [4J, clause 11.14. 

FUl DLC frame [NG1.D.5]: bidirectional frame used in LUl service. Defined in EN 300 175-4 [4], clause 12.2. 
Frame length depends on slot type and is defined in table 12.2.1.1 of EN 300 175-4 [4], clause 12.2.1. 

FU7 DLC frame [NG1.D.6]: bidirectional frame used in LU7 service. Defined in EN 300 175-4 [4], clause 11.9. 

FU12 DLC frame with adaptation for codec G.729.1 [NG1.D.7]: bidirectional frame used in LUl 2 service, as 
defined in EN 300 175-4 [4], clause 12.12, frame size specified for full slot, 2-level modulation and with the adaptation 
for codec G.729.1 defined in EN 300 175-4 [4], clause E.l. 



F.1 .4 New Generation DECT; part 1 , Medium Access Control 
(IVIAC) services (clause 5.4 of TS 102 527-1) 

lN_minimum delay symmetric MAC service type [NG1.M.1]: lN_minimum delay symmetric cormection as defined 
in EN 300 175-3 [3], clause 5.6.2.1. 

lN_normal delay symmetric MAC service type [NG1.M.2]: lN_normal delay synmietric cormection as defined in 
EN 300 175-3 [3], clause 5.6.2.1. 

IpQ_error_detection symmetric MAC service type [NG1.M.3]: Ipq_ error_detection symmetric connection as defined 
in EN 300 175-3 [3], clause 5.6.2.1. (type 3: Ip_ error_detection with single- subfield protected B-field as defined in 
EN 300 175-3 [3], clause 6.2.1.3.4). 

Advanced Connections [NG1.M.4]: MAC Connection Oriented service providing connection between FT and PT. 
Advanced connections are able to support multiple bearers, bearers different of the full slot, and any MAC service. The 
service includes the means for setting-up and releasing the required bearer(s). 

F.I .5 New Generation DECT; part 1 , Physical Layer (PHL) 
services (clause 5.5 of TS 102 527-1) 

2 level GFSK modulation [NG1.P.1]: 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 
EN 300 175-2 [2], clause 5. 

Physical Packet P32 [NG1.P.2]: physical packet P32 (fiiU slot) as defined by EN 300 175-2 [2], clause 4.4.2. 

Physical Packet P64 [NG1.P.3]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
withj =640. 

Physical Packet P67 [NG1.P.4]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
withj =672. 

Physical Packet P80 [NG1.P.5]: physical packet P80 (double slot) as defined by EN 300 175-2 [2], clause 4.4.4. 



F. I .6 New Generation DECT; part 1 , Speech coding and audio 

features (clause 5.6 of TS 102 527-1) 

G. 726 32 kbit/s ADPCM [NGl.SC.l]: ITU-T Recommendation G.726 [15] narrow band codec as defined by 

EN 300 175-8 [8], clause 5.1. ITU-T Recommendation G.726 [15] codec is mandatory for New Generation DECT in 
order to ensure interoperability with existing DECT systems. 

G.711 64 kbit/s log-PCM [NG1.SC.2]: ITU-T Recommendation G.711 narrow band codec [16] as defined by 

EN 300 175-8 [8], clause 5.2. ITU-T Reconnmendation G.711 [16] codec is optional for New Generation DECT in order 

to improve the quality of narrow band communications, and fax/modem transmissions. ITU-T Recommendation 
G.71 1 [16] provides a slightly higher intrinsic voice quality and no transcoding for PSTN calls. Both, A-Law and 
|A-Law are supported. 
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G.722 64 kbit/s wideband [NG1.SC.3]: ITU-T Recommendation G.722 wideband SB-ADPCM 7 kHz codec [17] as 
defined by EN 300 175-8 [8], clause 5.3. ITU-T Recommendation G.722 [17] is chosen as mandatory wideband codec 
for New Generation DECT in order to greatly increase the voice quality by extending the bandwidth from narrow band 
to wideband. ITU-T Recommendation G.722 [17] provides a high wideband quality at a bit rate of 64 kbit/s with low 
complexity and very low delay. 

G.729.1 32 kbit/s wideband [NG1.SC.4]: ITU-T Recommendation G.729.1 wideband codec [18] as defined by 
EN 300 175-8 [8], clause 5.4. ITU-T Recommendation G.729.1 [18] codec is optional for New Generation DECT in 

order to provide even higher wideband quality and better robustness to packets/frames losses than 

ITU-T Recommendation G.722 [17] at half the bit rate of ITU-T Recommendation G.722 [17]. This allows a better 

transport efficiency on the network side and over the DECT air interface (one full slot). In addition, it is seamless 

interoperable with largely deployed ITU-T Recommendation G.729 [i.7] based VoIP networks and terminals. 

ITU-T Recommendation G.729.1 [18] encodes signals in frames of 20 ms. It is a scalable codec operating at bitrates of 

8 kbit/s and from 12 kbit/s to 32 kbit/s per steps of 2 kbit/s, in narrow band or in wideband from 14 kbit/s. 

ITU-T Recommendation G.729.1 [18] already incorporates a high efficiency packet loss concealment mechanism. 

MPEG-4 ER AAC-LD 64 kbit/s super wideband [NG1.SC.5]: MPEG-4 ER AAC-LD codec [19], [20] as defined by 
EN 300 175-8 [8] clause 5.5.1. MPEG-4 ER AAC-LD is optional for New Generation DECT in order to provide higher 
quality than G.722 by further extending the bandwidth to superwideband (50 Hz to 14 kHz) (and even further, up to full 
audio bandwidth (20 Hz to 20 kHz)). MPEG-4 ER AAC-LD is designed for high quality communication applications 
including all kind of audio signals e.g. speech and music and provides a high quality for music streaming or other 
multimedia applications mixing speech and music. It provides an audio bandwidth of 14 kHz or more at a bitrate of 
64 kbit/s. MPEG 4 ER AAC-LD (Error resiUent, Low Delay AAC profile) is standardized as an audio profile [19] of 
MPEG-4 (ISO/IEC 14496-3 [20]). The frame size is 10 ms and the algorithmic delay 20 ms. 

MPEG-4 ER AAC-LD 32 kbit/s wideband [NG1.SC.6]: As [NG1.SC5], but using the 32 kbit/s mode, as defined by 
EN 300 175-8 [8], clause 5.5.2. It provides a bandwidth of 11,5 kHz or more. The frame size is 20 ms and the 
algorithmic delay 40 ms. 

PLC (Packet Loss Concealment) G.722 Appendix III & IV [NG1.SC.7]: To better cope with transmission errors, a 
Packet Loss Concealment algorithm (PLC) as defined by EN 300 175-8 [8], clause 5.3.2 may be optionally 
implemented for ITU-T Recommendation G.722 [17]. Appendices III and IV describe packet loss concealment 

solutions extending the ITU-T Recommendation G.722 [17] decoder. These PLC algorithms may be optionally 
implemented to improve voice quality in degraded transmission conditions where packets/frames may be lost (in IP 
network or on DECT air interface). 

NOTE 1: Both appendices meet the same quality requirements but address two different quality/complexity trade 
offs: 

1) Appendix III aims at maximizing the robustness at a price of additional complexity. 

2) Appendix IV proposes an optimized complexity/quality trade off with almost no additional 
complexity compared with ITU-T Recommendation G.722 [17] normal decoding (0,07 WMOPS). 

Since ITU-T Recommendation G.722 [17] does not incorporate any mechanism to cope with lost frames/packets, the 
use of a PLC algorithm is strongly recommended to avoid annoying effects in case of packet/frame losses. 

NOTE 2: ITU-T Recommendation G.729.1 [18] already incorporates a packet loss concealment mechanism. 

Detection of Modem/fax tone [NG1.SC.8]: Detection of the 1 100 Hz, 1 300 Hz and 2 100 Hz standard tones 
indicating a fax/modem transmission and answering, as defined by EN 300 175-8 [8] clause 5.2.2. The main utility of 
this function is the switching of codecs to transparent PCM (ITU-T Recommendation G.711 [16]) in order to facilitate 
modem/fax transmission. The tone detection can also be used to de-activate echo suppression if present. 

Codec selection and switching [NG1.SC.9]: To handle several codecs (at least ITU-T Recommendation G.726 [15] 
and 

ITU-T Recommendation G.722 [17]), New Generation DECT will support a codec selection and switching mechanism. 
This may consequently allow the use of other codecs that could be specified in next releases as additional optional 
codecs according to future application or interoperability needs. 

PP Audio type la ("classic GAP" handset) [NGl.SC.lO]: Audio specification for a general purpose 3,1 kHz 
telephony handset as defined by EN 300 175-8 [8], clause 7.2.3. 
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PP audio type lb ("improved GAP" handset) [NGl.SC.ll]: Audio specification for a general purpose 3,1 kHz 
telephony handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and 
long delay networks. 

PP audio type Ic (HATS tested, 3,1 kHz handset) [NG1.SC.12]: Audio specification for a general purpose 3,1 kHz 

telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [NG1.SC.13]: Audio specification for a general 
purpose 3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 

EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP Audio type 2a (ITU-T Recommendation P.311 [i.6] 7 kHz handset) [NG1.SC.14]: Audio specification for a 
wideband, 7 kHz service, handset based on the ITU-T Recommendation P.311 [i.6], as defined by EN 300 175-8 [8], 
clause 7.2.9. 

PP Audio type 2b (HATS 7 kHz handset) [NG1.SC.15]: Handset for 7 kHz service (wideband), based on HATS 
methodology, as defined by EN 300 175-8 [8], clause 7.2.10. It includes strong echo suppression (TCLw) requirements 
and is compatible with VoIP and long delay networks. 

PP Audio type 2c (HATS 7 kHz "improved" handset) [NG1.SC.16]: Handset for 7 kHz service (wideband), based 
on HATS methodology, with improved quality, as defined by EN 300 175-8 [8], clause 7.2.11. It includes strong echo 
suppression (TCLw) requirements and is compatible with VoIP and long delay networks. This type has a more 
demanding acoustic specification, providing superior subjective quaHty. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [NG1.SC.17]: Audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type apphes to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [NG1.SC.18]: Audio specification for a 
Narrowband (3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This 
type apphes to handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quahty. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 4a (HATS 7 kHz handsfree) [NG1.SC.19]: Wideband (7 kHz) handsfree device, as defined by 
EN 300 175-8 [8], clause 7.2.12. This type applies to handsfree devices operating with an open loudspeaker and 
microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 
It provides (150 Hz to 7 kHz) frequency range, and it is defined based on HATS methodology. 
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PP Audio type 4b (HATS 7 kHz "improved" handsfree) [NG1.SC.20]: Wideband (7 kHz) handsfree device, 
improved quality version, as defined by EN 300 175-8 [8], clause 7.2.13. This type applies to handsfree devices 
operating with an open loudspeaker and microphone. The profile appUes to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (150 Hz to 7 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 5a (Super wideband 14 kHz) [NG1.SC.21]: Handset for 14 kHz service (super wideband), as defined 
by EN 300 175-8 [8], clause 7.2.14. 

PP Audio type 5b (Super wideband 14 kHz, handsfree) [NG1.SC.22]: Handsfree device for 14 kHz service (super 
wideband), as defined by EN 300 175-8 [8], clause 7.2.15. 

FP audio type lb ("new ISDN" 3,1 kHz) [NG1,SC.23]: Audio specification for a DECT FP supporting narrowband 
service and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new 
specification, as defined by EN 300 175-8 [8J, clause 7.3.3. 

NOTE 3: FP Audio type la ("classic ISDN", 3,1 kHz FP, see EN 300 175-8 [8]) is not to be used in in New 

Generation DECT equipment. Instead of it, FP type lb should be used in NG-DECT FPs with ISDN or 
digital circuit- switch interfaces. 

PP echo canceller for FP, narrowband (3,1 kHz) service [NG1.SC.24]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only 
narrowband echo cancellation capability is required for this feature. 

PP echo supressor for FP, narrowband (3,1 kHz) service [NG1.SC.25]: Auxihary feature for FPs consisting on echo 
supressor for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only 
narrowband capability is required for this feature. 

FP audio type 2 (analog PSTN 3,1 kHz) [NG1.SC.26]: Audio specification for a DECT FP supporting narrowband 
service and providing an analog 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [NG1.SC.27]: Audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.71 1 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP Audio type 4 (ISDN, wideband) [NG1.SC.28]: Audio specification for a DECT FP supporting wideband service 
and providing a digital 64 kbit/s interface, typically (but not necessarily) an ISDN connection, with a wideband codec 
such as G.722, MPEG, etc. As defined by EN 300 175-8 [8], clause 7.3.6. 

FP Audio type 5 (VoIP wideband) [NG1.SC.29]: Audio specification for a DECT FP supporting wideband service 
and providing a VoIP interface, with a wideband codec on top such as G.722, MPEG, etc. As defined by 
EN 300 175-8 [8], clause 7.3.8. 

PP echo canceller for FP, wideband (7 kHz) service [NG1.SC.30]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.2. Only wideband 
echo cancellation capabiUty is required for this feature. 

PP echo supressor for FP, wideband (7 kHz) service [NG1.SC.31]: Auxiliary feature for FPs consisting on echo 
supressor for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.3. Only wideband 
echo cancelation capability is required for this feature. 

FP audio type 6a (internal call) [NG1.SC.32]: This type of audio specification applies to the case of internal call 
inside a DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 
EN 300 175-8 [8], clause 7.3.8. 
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FP audio type 6b (internal conference) [NG1.SC.33]: This type of audio specification applies to the case of 3-party 
or multi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 

Adaptive volume control for FP [NG1.SC.34]: Accessory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation shall be symmetrical. As described in 
EN 300 175-8 [8], clause 7.6 and informative annex D. 



F.2 Services and features defined in EN 300 444 (GAP) 

The following informative annex shows the features and MAC/DLC services defined in EN 300 444 [12] (GAP), many 
of them are reused in the present document. This list is informative, and shows the status in EN 300 444 [12] (V2.2.1). 
In case of changes or divergences the original definitions at EN 300 444 [12] (GAP) shall rule. 

F.2.1 GAP Network (NWK) features (clause 4.1 of EN 300 444) 

outgoing call [N.l]: call initiated at a DECT PP. 

off-hook [N.2]: ability to indicate the action of going off-hook, e.g. to start call setup or accept a call. 

on-hook (FULL Release) [N.3]: ability to indicate the action of going on-hook (e.g. to terminate a call) and fully 

release the radio resource. 

dialled digits (basic) [N.4]: capabiUty to dial digits to 9, *, #. 

register recall [N.5]: ability of the PP to request the invocation of the supplementary service "register recall" over the 

DECT interface and the ability of the FP to transmit the request to the local network. 

Register recall means to seize a register (with dial tone) to permit input of further digits or other action. 

go to DTMF signalling (defined tone length) [N.6]: go to DTMF signalUng with defined tone length. 

pause (dialling pause) [N.7]: ability to generate or indicate a dialling pause, e.g. to await further dial tone. 

incoming call [N.8]: call received at a DECT PP. 

authentication of PP [N.9]: process by which the identity of a DECT PP is checked by the FP. 

authentication of user [N.IO]: process by which the identity of a user of a DECT PP is checked by the FP. The User 
Personal Identification (UPI), a personal identification of to 8 digits, manually entered by the user, is used for user 
authentication. 

location registration [N.ll]: facility whereby a PP can be registered with a FP or a cluster of FPs such that incoming 
calls, radio pages or messages may be routed to it. 

on-air key allocation [N.12]: capability to transform Authentication Code (AC) into User Authentication Key (UAK) 
using the key allocation procedure. 

identification of PP [N.13]: ability for the FP to request and PP to provide specific identification parameters. 

service class indication/assignment [N.14]: assignment by the FP to PP of the service class and indication to the FP by 

the PP of the contents of its service class. 

alerting [N.15]: activates or deactivates alerting at the PP using any appropriate indication. 

ZAP [N.16]: ability first to assign and then to re-program the account data held in the PP so that access rights may be 
suspended subject to the conditions set by the service provider being met, coupled with the ability to re-program the 
account data again to reinstate access rights once these conditions have been met. 

One ZAP field shall be provided per account field. The PP has the right to authenticate the FP prior to the execution of 

ZAP suspend. 

encryption activation FT initiated [N.17]: activation of the encryption process requested by FT. 
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subscription registration procedure on-air [N.18]: standardized procedure for loading subscription registration data 

into a PP in real time over the air-interface. 

link control [N.19]: ability to request, accept, maintain and release a data link for the purposes of a NWK layer 
procedure. 

terminate access rights FT initiated [N.20]: abihty of the FP to delete a subscription in the PP. 

partial release [N.21]: ability to release an established or in progress Call Control (CC) call whilst retaining the radio 
resource for the purpose of accessing further services. 

go to DTMF (infinite tone length) [N.22]: go to DTMF signalling, indicating infinite DTMF tone duration, 
go to pulse [N.23]: go to pulse (decadic) signalling. 

signalling of display characters [N.24]: transmission to the PP of characters to be displayed on the user's PP display 
(if provided). 

display control characters [N.25]: characters sent to the PP to control the user's display in the PP (if provided) 
Such characters include cursor control, clear screen, home, flash, inverse video, etc. 

authentication of FT [N.26]: process by which the identity of a FP is checked by the PP. 

encryption activation PT initiated [N.27]: activation of the encryption process suggested by PT. 
The real time start of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation FT initiated [N.28]: deactivation of the encryption process requested by FT. 
The real time stop of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation PT initiated [N.29]: deactivation of the encryption process suggested by PT. 
The real time stop of ciphering is done in the MAC layer and is always initiated by the PT. 

CalUng Line Identification Presentation (CLIP) [N.30]: abihty to provide the calling party number to the called party 
before accepting the call. 

internal call [N.31]: call between 2 users that does not make use of the local network resources. 
This is typically useful in residential envirormients. 

service call [N.32]: call initiated by a DECT PT for entering of FT related service and adjustment procedures in a 
transparent way. 

After having sent the service call indication, the PT behaves according to the rules of a normal call. 

Enhanced U- plane connection [N.33]: ability of the FT to initiate connection of the U- plane during call 
establishment or release e.g. to facilitate the provision of in band tones or announcements. 

Calling Name Identification Presentation (CNIP) [N.34]: ability to provide the calling party name to the called party 
before accepting the call. 

Enhanced Security [N.35]: mechanism to enhance DECT security by introduction of early encryption and the 
possibihty of re-keying during an ongoing call. 

F. 2.2 GAP Speech coding and audio features (clause 4.2 of 

EN 300 444) 

For the purposes of the present document the following definitions shall apply: 

G. 726 32 kbit/s ADPCM [SC.l]: ITU-T Recommendation G.726 [15] narrow band codec as defined by 
EN 300 175-8 [8] clause 5.1. 

PP audio type la ("classic GAP" handset) [SC.2]: Audio specification for a general purpose 3,1 kHz telephony 
handset as defined by EN 300 175-8 [8], clause 7.2.3. 
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PP audio type lb ("improved GAP" handset) [SC.3]: Audio specification for a general purpose 3,1 kHz telephony 
handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and long delay 
networks. 

PP audio type Ic (HATS tested, 3,1 kHz handset) [SC.4]: Audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 IsHz "improved" handset) [SC.5]: Audio specification for a general purpose 
3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 

EN 300 175-8 |8|, clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [SC.6]: Audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 
It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [SC.7]: Audio specification for a Narrowband 

(3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This type applies to 
handsfree devices operating with an open loudspeaker and microphone. The type appUes to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

FP audio type la ("classic ISDN" 3,1 kHz) [SC.8]: Audio specification for a DECT FP supporting narrowband 
service and providing a digital 64 kbit/s G.711 interface, typically (but not necessarily) an ISDN connection, classic 
specification, as defined by EN 300 175-8 [8], clause 7.3.2. It is recommended to use FP type lb instead of type la. 

FP audio type lb ("new ISDN" 3,1 kHz) [SC.9]: Audio specification for a DECT FP supporting narrowband service 
and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new specification, 
as defined by EN 300 175-8 [8], clause 7.3.3. It is recommended to use FP type lb instead of type la. 

PP echo canceller for FP [SC.IO]: Auxiliary feature for FPs consisting on echo canceller for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only narrowband echo cancellation capability 
is required. 

PP echo supressor for FP [SC.ll]: Auxiliary feature for FPs consisting on echo supressor for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only narrowband capability is required. 

FP audio type 2 (analog PSTN 3,1 kHz) [SC.12]: Audio specification for a DECT FP supporting narrowband service 
and providing an analog 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (Voff 3,1 ItHz) [SC.13]: Audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.711 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP audio type 5a (internal call) [SC.14]: This type of audio specification applies to the case of internal call inside a 
DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 
EN 300 175-8 [8], clause 7.3.8. 
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FP audio type 5b (internal conference) [SC. 15]: This type of audio specification applies to the case of 3-party or 
multi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 

Adaptive volume control for FP [SC.16]: Accesory feature for FPs consisting on an adaptive volume control 

depending on the level of environmental noise at the PP. The gain variation shall be symmetrical. As described in 
EN 300 175-8 [8], (detailed descriptions for each type of FP in clause 7.6, and examples of settings in annex D). 

F.2.3 GAP Application features (clause 4.3 of EN 300 444) 

AC to bitstring mapping [A.l]: Mapping of the AC into a bitstring. 

multiple subscription registration [A.2]: Ability of PP to store more than one subscription. 

manual entry of the Portable Access Rights Key (PARK) [A.3]: Ability of the PP to accept a manual entry of the 
PARK for ensuring attachment to the right FP in a physical area covered by many providers. 

terminal identity number assignment in mono-cell system [A.4]: Ability to assign to each PT a terminal identity 
number. 

F.2.4 DLC service definitions (clause 5.1 of EN 300 444) 

LAPC class A service and Lc [D.l]: single frame acknowledged C-plane data link service providing a single data link 
between one FT and one PT. 

The higher layer information is segmented (if necessary) and transmitted in numbered frames. The Lc provides frame 
delimiting, transparency and frame synchronization. 

Cs channel fragmentation and recombination [I).2]: Lc service providing channel dependant fragmentation (by 
means of dividing a LAPC data unit into more than one service data units for delivery to the MAC layer Cs logical 
channel) and recombination (by means of joining several service units received from the MAC layer Cs logical channel 
into a LAPC data unit). 

broadcast Lb service [D.3]: simplex point- to-multipoint transmission using simple fixed length DLC frames providing 
a restricted broadcast service in direction FP to PP(s). 

intra-cell voluntary connection handover [D.4]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC cormection to a second new MAC connection in the domain of the same 
cell, while maintaining the service provided to the NWK layer. 

intercell voluntary connection handover [D.5]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection not in the domain of the 
same cell, while maintaining the service provided to the NWK layer. 

encryption activation [D.6]: transporting the NWK layer encryption request and the cipher key to the MAC layer, 
thereby enabling the encryption process in the MAC layer. 

LUl TRansparent Unprotected service (TRUP) class 0/min_delay [D.7]: transparent unprotected service 
introducing minimum delay between the higher layers and the MAC layer. 

May be used for speech and non-speech appUcations. Speech transmission shall only use the class 0/min_delay 
operation over a single bearer MAC connection. Data integrity is not guaranteed. No error protection is applied, and 

octets may be lost, erroneous or duplicated. The continuous higher layer data is fragmented for delivery to the 1^ logical 
channel in the transmission direction, and recombined from the In logical channel in the receiving direction. 

FUl [D.8]: offers a defined fixed length frame structure and buffering functions for transmission of U-plane data to the 
MAC layer (at the transmit side) or accept of data from the MAC layer (at the receiving side) on demand and with 
minimum delay. Used for speech but may be used for more general data purposes. 

encryption deactivation [D.9]: transporting the NWK layer encryption deactivation request to the MAC layer, thereby 
disabling the encryption process in the MAC layer. 
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F.2.5 GAP MAC service definitions (clause 5.2 of EN 300 444) 

general [M.l]: set of basic requirements regarding data formats, multiplexing, CRC usage, scanning and locking, 
which are prerequisites to conmiunication between peer MAC entities. 

continuous broadcast [M.2]: simplex service from FT to PT whereby the FT maintains at least one bearer with 

continuous transmissions. 

The PT can use the information carried in this bearer to lock to the FT and to obtain knowledge about the FT. 

paging broadcast [M.3]: service whereby the identities of specific PTs can be broadcast by the FT. This service is 
normally used by the FT to request a specific PT to set up a Unk to the FT. 

basic connection [M.4]: service providing connection between FT and VT consisting of one full slot duplex bearer 
supporting the In_minimum_delay data service (i.e. speech). 

Only one basic connection may exist between a FT and particular PT (except during connection handover). The service 
includes the means for setting-up and releasing the required bearer(s). 

Cs liiglier layer signalling [M.5]: low rate connection oriented data service with ARQ using the Cs channel to transfer 
higher layer signalling data. 

quality control [M.6]: provides means for monitoring and controlUng the radio link quality. 

encryption activation [M.7]: service providing means for enabling the encryption whereby on demand aU higher layer 
data (including speech) is transferred across the AI in an encrypted form. 
Always initiated by the PT. 

extended frequency allocation [M.8]: service which allows a FT to support frequencies in addition to the standard 
DECT frequencies. 

bearer handover - intra-cell [M.9]: internal MAC process whereby data transfer (C channel and I channel) is switched 
from one duplex bearer to another in the domain of the same cell while maintaining the service to the DLC layer. 

bearer handover - inter-cell [M.IO]: internal MAC process whereby data transfer (C channel and I channel) is 
switched from one duplex bearer to another not in the domain of the same cell while maintaining the service to the DLC 
layer. 

connection handover - intra-cell [M.ll]: in the MAC layer, it is the process enabling setting up a new basic 
connection in the domain of the same cell to support connection handover at the DLC layer. 

connection handover - inter-cell [M.12]: in the MAC layer, it is the process enabling setting up a new basic 
connection not in the domain of the same cell to support connection handover at the DLC layer. 

Secondary Access Rights Identity (SARI) support [M.13]: ability to support, in addition to the primary Access 
Rights Identity (ARI), secondary ARIs that the FT broadcasts less frequently than PARIs. 

These may be used to reflect an inter-operators agreement allowing a portable to access more than one operator or 
services through FT. 

encryption deactivation [M.14]: service providing means for disabling the encryption whereby on demand the process 
of transmitting higher layer data (including speech) across the AI in encrypted form is to be cancelled (a connection 
release automatically disables ciphering). 

Re-keying [M.15]: mechanism to change the cipher key during an ongoing call. 

Early encryption [M.16]: mechanism to activate encryption immediately after connection establishment. 



F.3 GAP Feature/service to procedure nnapping tables 

The following informative annex shows the features/service to procedure mapping tables as defined in EN 300 444 [12] 
(GAP), that are reused in the present document (unless other specification is given). This list is informative, and shows 
the status in EN 300 444 [12] V2.2.1. In case of changes or divergences the original tables at EN 300 444 [12] (GAP) 
shall rule. 
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F.3.1 GAP NWK feature to procedure mapping table (clause 6.8.1 
of EN 300 444) 



Table F.1 : NWK feature to procedure mapping (table 5 of EN 300 444) 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


N.1 Outgoing call 




4.1 


IVl 


M 


M 


Outgoing call request 


8.2 


M 


M 


M 


Overlap sending 


8.3 


IVl 








Outgoing call proceeding 


8.4 


M 








Outgoing call confirmation 


8.5 


M 








Outgoing call connection 


8.6 


M 


M 


M 


Sending keypad information 


8.10 


M 


M 


M 


N.2 Off Hook 




4.1 


M 


M 


M 


Outgoing call request 


8.2 


M 


M 


M 


Incoming call connection 


8.15 


M 


M 


M 


N.3 On Hook (full release) 




4.1 


M 


M 


M 


Normal call release 


8.7 


M 


M 


M 


Abnormal call release 


8.8 


M 


M 


M 


■l 1 A II 1 1" /I "V 

N.4 Dialled digits (basic) 




4.1 


M 


M 


M 


Sending keypad information 


8.10 


M 


M 


M 


N.5 Register recall 




4.1 


M 








Sending keypad information 


8.10 


M 


M 


M 


N.6 Go to DTIVIF signalling 
(defined tone lengtii) 




4.1 


M 





M 


Sending keypad information 


8.10 


IVl 


M 


M 


k 1 r~\ / _i ■ 1 1 ■ \ 

N.7 Pause (dialling pause) 




4.1 


M 








Sending keypad information 


8.10 


IVl 


M 


M 


N.8 Incoming call 




4.1 


M 


M 


M 


Incoming call request 


8.12 


M 


M 


M 


Incoming call confirmation 


8.13 


M 


M 


M 


PT alerting 


8.14 


M 


M 


M 


Incoming call connection 


8.15 


M 


M 


M 


N.9 Authentication of tfie PP 




4.1 


M 


C501 


M 


Authentication of PT 


8.24 


M 


M 


M 


N10 Auttientication of tine user 




4.1 


M 








Authentication of user 


8.25 


M 


M 


M 


N.11 Location registration 




4.1 


IVl 





M 


Location registration 


8.28 


M 


M 


M 


Location update 


8.29 


M 








Terminal Capability indication 


8.17 











N.1 2 On air key allocation 




4.1 


M 


C501 





Key allocation 


8.32 


M 


M 


M 


N.1 3 Identification of PP 




4.1 


M 








Identification of PT 


8.22 


M 


M 


M 


N.1 4 Service class 
indication/assignment 




4.1 


M 





M 


Obtaining access rights 


8.30 


M 


M 


M 


Terminal Capability indication 


8.17 











Authentication of PT 


8.24 


M 


M 


M 


N.1 5 Alerting 




4.1 


M 


M 


M 


PT alerting 


8.14 


IVl 


M 


M 


N.1 6 ZAP 




4.1 


M 








Obtaining access rights 


8.30 


M 


M 


M 


Terminal Capability indication 


8.17 











Incrementing the ZAP value 


8.26 


M 


M 


M 


Authentication of FT 


8.23 





M 


M 


N.1 7 Encryption activation FT 
initiated 




4.1 


M 


C501 


M 


Cipher-switching initiated by FT 


8.33 


M 


M 


M 


Storing the Derived Cipher Key (DCK) 


8.27 


M 


M 


M 
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Feature/Procedure mapping 




Status 


Feature 




Rpf p rp n OP 


PT 


FT 










R/B 


p 


procedure on-air 




4.1 


M 


M 


M 


Ohtaininn spppqq rinhtQ 
v-zuidi 1 1 II 1^ ciooc^oo ii^iiLo 


o.ou 


M 


M 


M 


Tprminal OanaKilitv/ inHi/^ation 

Idlllllldl OCl)JClUIIILy II lUIUCtLIUI 1 


O. 1 / 




n 


n 


M 1 Q 1 ink prvntrni 




1". 1 


IVI 


M 


M 


InHirppt PX initiatpri link PQtahliQhmpnt 

II lUI 1 CLf I 1^ 1 1 1 1 1 LlCtlCU 1 1 1 lf\ ColCtL/l lol II 1 id 1 L 




M 


M 


M 


r)irQr«t PX initiatpri link PQtaKliQhmpnt 

L/ 1 1 I F 1 1 1 1 1 LICtlCU 1 1 1 ir\ ColdliJI lol II 1 Id 11 




M 


M 


M 


1 ink rolpacp "nnrmal" 
i_ii ir\ 1 t:^ic;cioC' iiwiiiicti 


o.o / 


IVI 


IVI 


IVI 


1 ink rolocaco "ahnnrmal" 
i_iiirv idt^dot; dui lui M idi 


o.oo 


IVI 


M 


M 


1 ink fpjppQp "mpintpin" 
i_iiii\ ic;iC7doc7 iiidiiiLdiii 


R RQ 


M 


M 


M 


M PO Tprminatp appoQC rinhtQ PT 

1 M.^W 1 KjI I I III ICtlC ClLfOCoo 1 1^1 ILo n 1 

initiated 




4.1 


M 






PX tprminatinn arr'Pcc rinhtc 
1 1 Id [ 1 III idLii ly dULiCoo iiyiiLo 


o.o 1 


IVI 


IVI 


IVI 


Ai ithpntipatinn rti FX 

nULI Id lllLfdllUI 1 Ul 1 1 


o.^o 


n 


M 


M 


Kl P1 Partial rplpaQP 




4.1 








Partial rp|pac;p 
1 diLidi 1 dCdoc 




IVI 


M 


M 


N.22 Go to DTMF (infinite tone 

Ipnnth^ 








n 


n 


^pnHinn kownarl infnrmatinn 
Od lUM ly rvuyjJdU ii iiui ii idiiui i 


O. 1 u 


IVI 


M 


M 


N.23 Go to Pulse 




4.1 






o 


^pnHinn kPunaH infnrmatinn 
ociiuiiiy rvcy [Jdvj ii iiui 1 1 idLiui i 


8 in 

O. 1 u 


M 


M 


M 


N.24 Signalling of display 
characters 




4 1 
t. 1 


n 


n 


n 


Plicniav/ 
uioiJidy 


SIR 

O. 1 u 


IVI 


M 


M 


Xprminpl ppn^ihilitx/ inrlioptinn 
1 t:7i 1 1 III idi LidL/dkJiiiiy ii lUiLidLiui i 


8.17 


M 


M 


M 


N.25 Display control characters 




4.1 


n 


n 


n 


niQnla\/ 
L^ioiJidy 


8 1 fi 

O. 1 u 


M 


M 


M 


Xprminal r'anahilit\/ inHir'ation 
lc;llllllldl UdpdUllliy lilUlOdllUll 


S 1 7 

O. 1 / 


IVI 


M 


M 


M Pfi Ai ithpntirfltinn nf FT 




4.1 




o 




Ai ithpntipatinn nf FX 

rAU LI Id 1 LIUdLIUI 1 \J\ I 1 


8 ?T 


M 


M 


M 


N.27 Encryption activation PT 
initi^^tpH 

■ III LICILWU 




4.1 








Oinhpr-c\A/itr'hi nn initiatpri h\/ PX 
oi|ji ic;i ovviiL>i III ly iiiiLidLcLi uy 1 1 


8 "^4 

O.OH- 


IVI 


M 


M 


9tnrinn thp DHK 

OIUI II ly LI IC L^Oi\ 


8 ?7 


M 


M 


M 


N.28 Encryption deactivation FT 

initiated 




4.1 








f^inhpr-Qwitfhinn initiatpH hv FX 
oi|ji Id ovviLOiiiiiy iiiiiidLCU uy i i 


8 

o.oo 


M 


M 


M 


N.29 Encryption deactivation PT 
initiatpd 

II 1 1 L 1 C\ L 




4 1 
t. 1 


n 




n 


f^ir^hpr-Qwitphinn initiatPrJ Kv PX 
oi|ji Id ovviLOiiiiiy iiiiLidLCU uy i i 


8 ^4 


M 


M 


M 


N.30 Calling Line Identification 
Presentation (CLIP) 




4.1 











Inpnminn ppII rpniiPQt 
II iL'Wii Ml ly Odii ic;i_|LJc;oL 


R 1 ? 


M 


M 


M 


Oallinn 1 inp IHpntifir'atir\n Prpcpntatinn 

Odillliy L.II IC lUCl ILIIIOdLIUI 1 r iCOd lldLIUI 1 


R 41 


IVI 


M 


M 


N.31 Internal call 




4.1 


n 








Internal call setup 


8.18 


M 


IVI 


IVI 


iiiicrridi udii txcypdu 


ft 1Q 


Kyi 

IVI 






inicrnal can OLIr 












Internal call CNIP 


8.44 





r\ 
U 


r\ 
U 


N.Oli oervice can 




4.1 


U 


U 


U 


O ' M 

Service call setup 


Q OA 


IVI 


IVI 


IVI 


Service call keypad 


o o^ 


^ yi 
IVI 


r\ 
U 


u 


N.33 Enhanced U- plane 
connection 




A H 
4.1 


U 


L) 


u 


Enhanced FT initiated U- plane 

OUI II IcOllUI 1 


0.4U 


IVI 


IVI 


IVI 


Lralliny iNalTfc IQcnilTICallOn 

Presentation (CNIP) 




A 1 










Calling Name Identification Presentation 
(CNIP) Indication 


8.42 


M 


M 


M 


N.35 Enhanced security 




4.1 











Encryption of all calls 


8.45.1 


M 


M 


M 


Re-keying during a call 


8.45.2 











Early encryption 


8.45.3 











Subscription requirements 


8.45.4 


M 


M 


M 


Behaviour against legacy devices 


8.45.5 


M 


M 


M 


C501 : IF feature N.35 THEN M ELSE 0. 
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F.3.2 GAP DLC service to procedure mapping table (clause 6.8.2 
of EN 300 444) 



Table F.2: DLC service to procedure mapping (table 6 of EN 300 444) 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 










R/B 


P 


D.1 LAPC class A service and Lc 




5.1 


M 


M 


M 


Class A link establishment 


9.1 


M 


M 


M 


Class A acknowledged information 
transfer 


9.2 


M 


M 


M 


Class A link release 


9.3 


M 


M 


M 


Class A link re-establishment 


9.4 


M 


M 


M 


D.2 Cs channel fragmentation and 
recombination 




5.1 


M 


M 


M 


Cs channel fragmentation and 
recombination 


9.5 


M 


M 


M 


D.3 Broadcast Lb service 




5.1 


M 


M 


M 


Normal broadcast 


9.6 


M 


M 


M 


D.4 Intra-cell voluntary connection 
liandover 




5.1 


M 


C601 


C601 


Class A basic connection handover 


9.7 


M 


M 


M 


D.5 Inter-cell voluntary connection 
handover 




5.1 


M 








Class A basic connection handover 


9.7 


M 


M 


M 


D.6 Encryption activation 




5.1 


M 


C603 


M 


Encryption switching 


9.8 


M 


M 


M 


D.7 LU1 TRUP Class 0/min_delay 




5.1 


M 


M 


M 


U-plane Class 0/min delay 


9.9 


M 


M 


M 


D.8 FU1 




5.1 


M 


M 


M 


FU1 frame operation 


9.10 


M 


M 


M 


D.9 Encryption deactivation 




5.1 


C602 


C602 


C602 


Encryption switching 


9.8 


M 


M 


M 


C601 : IF service M.9 THEN ELSE M. 

C602: IF feature N.29 OR N.28 THEN M ELSE 1. 

C603; IF feature N.17 OR N.27 THEN M ELSE 1. 
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F.3.3 GAP MAC service to procedure mapping table (clause 6.8.3 
of EN 300 444) 

Table F.3: MAC service to procedure mapping (table 7 of EN 300 444) 



Service/Procedure mapping 





Status 


Service 


Procedure 


Reference 


PT 


FT 










R/B 


P 


M.I General 




5.2 


M 


M 


M 


General 


10.1 


M 


M 


M 


M.2 Continuous broadcast 




5.2 


M 


M 


M 


Downlink broadcast 


10.2 


M 


M 


M 


Higher layer information FP broadcast 


13.6 


M 


M 


M 


M.3 Paging broadcast 




5.2 


M 


M 


M 


Paging broadcast 


10.3 


M 


M 


M 


Higher layer information FP broadcast 


13.6 


M 


M 


M 


MA Basic connections 




5.2 


M 


M 


M 


Setup of basic connection, basic bearer 
setup (A-field) 


10.4 


M 


M 


M 


Connection/bearer release 


10.5 


M 


M 


M 


IVi.S Cs higtier layer signalling 




5.2 


M 


M 


M 


Cs channel data 


10.8 


M 


M 


M 


Q2 bit setting 


10.9 


M 


M 


M 


M.6 Quality control 




5.2 


M 


M 


M 


RFPI handshake 


10.10 


M 


M 


M 


Antenna diversity 


10.11 


M 








Sliding collision detection 


10.12 





M 


M 


M.7 Encryption activation 




5.2 


M 


C704 


M 


Encryption process - initialization and 
synchronization 


10.13 


M 


M 


M 


Encryption mode control 


10.14 


M 


M 


M 


Handover encryption process 


10.15 


M 


M 


M 


M.8 Extended frequency 
allocation 




5.2 


M 








Extended frequency allocation 


10.18 


M 


M 


IVI 


M.9 Bearer handover, intra-cell 




5.2 


M 


C701 


C701 


Bearer handover request 


10.6 


M 


M 


M 


M.10 Bearer handover, inter-cell 




5.2 


M 








Bearer handover request 


10.6 


M 


M 


M 


M.11 Connection handover, 
intra-cell 




5.2 


M 


C702 


C702 


Connection handover request 


10.7 


M 


M 


IVI 


M.12 Connection handover, 
inter-cell 




5.2 


M 








Connection handover request 


10.7 


M 


M 


IVI 


M.13 SARI support 




5.2 


M 








Downlink broadcast 


10.2 


M 


M 


M 


Higher layer information FP broadcast 


13.6 


M 


M 


M 


M.14 Encryption deactivation 




5.2 


C703 


C703 


C703 


Encryption mode control 


10.14 


M 


M 


M 


M.15 Re-keying 




5.2 


C705 


C705 


C705 


Re-keying 


10.17 


M 


M 


M 


M.I 6 Early encryption 




5.2 


C706 


C706 


C706 


Early encryption 


10.18 


M 


M 


M 



C701: IF service M.11 THEN O ELSE M. 

C702; IF service M.9 THEN O ELSE M. 

C703: IF feature N.29 OR N.28 THEN M ELSE I. 

C704: IF feature N.I 7 OR N.27 THEN M ELSE I. 

C705: IF feature N.35 and NWK layer procedure "Re-keying during a call" are implemented THEN M ELSE O. 

C705: IF feature N.35 and NWK layer procedure "Early encryption" are implemented THEN M ELSE O. 
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F.3.4 GAP Application feature to procedure mapping table 
(clause 6.8.4 of EN 300 444) 



Table F.4: Application feature to procedure mapping table (table 8 of EN 300 444 [12]) 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


A.1 AC to bitstring mapping 




4.3 


M 


C801 


M 


AC to bitstring mapping 


14.2 


M 


M 


M 


A.2 Multiple subscription 
registration 




4.3 


M 


N/A 


N/A 


Subscription control 


14.1 


M 


N/A 


N/A 


A.3 Manual entry of the PARK 




4.3 





N/A 


N/A 


Manual entry of the PARK 


14.3 


M 


N/A 


N/A 


A. 4 Terminal identity number 
assignment in mono cell system 




4.3 








N/A 


Terminal identity number assignment 


14.4 








N/A 


C801 : IF feature N.9 OR N.1 OR N.1 2 OR N.26 THEN M ELSE N/A. 
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